Что лучше для бизнеса: облака или on-premise? Узнаем уже завтра, 28 августа в 15:00 по Москве.
Приглашаем на экспресс-вебинар, где обсудим, зачем переходить в облако и кому это нужно. И посмотрим реальные результаты на примере успешной миграции авиакомпании Smartavia.
Каждый участник прямого эфира сможет задать свои вопросы и получить промокод на скидку на разовые работы.
28 августа проведём открытый экспресс-вебинар «Облако vs On-premise: что выбрать для надёжного бизнеса?»
☁️ Классно, когда бизнес переходит на новый этап развития, масштабируется и стремится перенести свои системы на более эффективные платформы. Такими платформами являются облака — современные, гибкие, динамические среды. Их и обсудим на нашем новом экспресс-вебинаре.
За 30 минут вебинара:
обсудим, зачем компаниям переходить в облако;
разберём плюсы и минусы on-cloud и on-premise решений;
посмотрим кейс авиакомпании Smartavia с реальными результатами;
рассчитаем влияние на бизнес Cloud Native в деньгах;
Всем DevOps! Автоматизация проверки одобрений merge requests с помощью GitLab CI/CD и GitLab API — это классный способ без лишних затрат оптимизировать процесс управления кодом в вашей команде.
Наш DevOps-инженер Виктор рассказал, как он смог настроить approve rules для merge request в бесплатной версии GitLab CE.
Из статьи вы узнаете, какие инструменты и методы он применил, а также получите советы по настройке и интеграции решения в ваш рабочий процесс.
Как упростить развёртывание инфраструктуры в облаке? С помощью проверенных Terraform-модулей из репозитория nxs-marketplace-terraform. О них и пойдёт речь в новой статье Данила, нашего DevOps-инженера.
На примере развертывания S3-бакета и Managed Kubernetes с worker-нодами вы увидите, как готовые Terraform-модули помогают ускорить работу и сократить вероятность ошибок. А ещё вы узнаете, зачем использовать динамические блоки в Terraform и почему файлы tfstate лучше хранить в S3.
Приглашаем на вебинар, где обсудим проблемы, с которыми может столкнуться компания с устаревшей IT-инфраструктурой. Ещё поговорим про кастомизацию инфраструктуры на примере клиентского кейса из сферы FoodTech.
Каждый участник прямого эфира сможет задать свои вопросы и получить промокод на скидку на разовые работы.
Когда мы особенно ярко чувствуем тесную связь разных компаний? Правильно: когда у одной из них случается сбой. Именно поэтому важно иметь надёжную IT-инфраструктуру, чтобы минимизировать проблемы не только у собственного, но и окружающего вас бизнеса.
На вебинаре:
обсудим тонкости и нюансы цифровой трансформации на примере FoodTech’а;
покажем, как справиться с нагрузками «в сезон продаж»;
разберём клиентский кейс с реальными результатами и цифрами;
Друзья! У Петра вышло продолжение серии обзорных статей про ClickHouse — open-source OLAP базу данных, ориентированную на колонки. В новой статье наш DevOps-инженер рассказывает про особенности репликации в этой СУБД.
Из этой части вы узнаете:
как работают сервисы координации Zookeeper и ClickHouse Keeper;
по какой причине может произойти падение репликации;
почему не следует очищать Keeper вручную.
Чтобы вспомнить, о чём Пётр рассказывал в первой части — нажмите сюда.
Всем DevOps! Однажды один из наших клиентов обнаружил, что резервные копии ClickHouse, которые он хранит в S3 провайдера CROC, не очень-то и шифруются. Была поставлена задача: настроить шифрование бэкапов.
В своей новой статье Николай, наш DevOps-инженер, показал, как мы это сделали. Он разобрал основные методы шифрования данных на стороне сервера в Amazon S3 — SSE-C, SSE-KMS и SSE-S3, расписал плюсы и минусы работы с clickhouse-backup и продемонстрировал, как легко восстановить данные из шифрованных бэкапов.
💻 Если ещё не читали, то нажмите сюда, чтобы начать.
Поначалу IBM не горела желанием внедрять наработки Кодда. В то время у компании была IMS, довольно успешная иерархическая база данных. Лишь спустя три года, в 1973 году, IBM запустила System R — исследовательский проект по изучению теории Кодда. Факт: сам Эдгар практически не принимал участия в разработке. Зато активно трудились двое других сотрудников IBM — Дон Чемберлин и Рэй Бойс, которые ещё до запуска проекта разработали SQUARE.
В синтаксисе SQUARE было много нижних индексов и некоторые математические обозначения. Печатать команды с клавиатуры было неудобно. Чемберлин и Бойс решили сделать язык более простым, таким, чтобы он напоминал структуру английского предложения. Так и появился SEQUEL, который потом переименовали в Structured Query Language — «язык структурированных запросов».
Первый выпуск SQL состоялся в июне 1974-го.
Как к SQL относился Тед Кодд? Он считал, SQL неправильно реализовывал теорию реляционной модели данных. В 1985-м Эдгар опубликовал «12 правил Кодда», описывающие, что должна содержать НАСТОЯЩАЯ реляционная СУБД. Стоит ли говорить, что SQL сам по себе не соблюдает их все?
Всем привет! Не docker'ом единым мы живы. Хочу показать, какими ещё вариантами обхода блокировки Docker Hub в России пользуется наша команда.
cri-o Добавьте в файл /etc/containers/registries.conf следующий блок: [[registry]] location = "docker.io"
[[registry.mirror]] location = "mirror.gcr.io" и перезагрузите cri-o. Можно не переживать за контейнеры, они ребутаться не будут.
containerd Нужно добавить или отредактировать блок plugins в /etc/containerd/config.toml: [plugins] [plugins."io.containerd.grpc.v1.cri"] [plugins."io.containerd.grpc.v1.cri".registry]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"] endpoint = ["https://registry-1.docker.io", "https://mirror.gcr.io"] и перезагрузить containerd. Здесь тоже можно не переживать за запущенные контейнеры.
Kaniko Если возникли проблемы при билде с помощью Kaniko, то можно решить проблему либо добавлением аргумента --registry-mirror mirror.gcr.io, либо с помощью переменной окружения KANIKO_REGISTRY_MIRROR="mirror.gcr.io". Мы, например, вынесли её на уровень админки GitLab, чтобы вообще не трогать .gitlab-ci.yml, поэтому рекомендуем воспользоваться именно переменной для более комфортного обхода блокировки.
Всем DevOps! Наш DevOps-инженер Данил выпустил очень полезный туториал для тех, кто только начинает своё знакомство с Kubernetes.
Если вы хотите понять, как развернуть кластер Kubernetes на собственных серверах с отказоустойчивым балансировщиком в виде MetalLB, то новая статья в нашем блоге придётся как раз кстати.
Вы узнаете, как связка MetalLB, Longhorn и Kubespray позволяет обойтись меньшим количеством виртуалок и построить закрытую, высокоэффективную систему, способную удовлетворить специфические потребности бизнеса.
Друзья, у Миши, нашего DevOps-инженера, вышла вторая часть серии про создание почтового сервера с чистого поля.
Вообще, создание почтовика — нетривиальная задача, которая требует внимания к деталям. Если вы хотите создать надёжный и эффективный почтовый сервер, который будет успешно функционировать и обслуживать пользователей, то вам помогут туториалы, которые пишет Миша.
В новой статье он показывает, как его настроить с помощью PostfixAdmin, Dovecot и RainLoop. А ещё в тексте вы найдёте немного экзотики, а именно best practices по Dovecot.
? Если вы ещё не читали, то вот ссылка. А здесь опубликована первая часть серии.
Всем DevOps! Станислав Тибекин, CEO компании Nixys, публикует перевод огромного и полезного чек-листа по разработке облачного приложения. Первая часть посвящена бизнес-требованиям.
Вы узнаете, что нужно учесть при разработке приложения, чтобы обеспечить отказоустойчивость, масштабируемость и непрерывность бизнеса.
Всем привет! Мы продолжаем обзор Redis — системы хранения данных в виде структур.
Новая статья Петра, нашего DevOps-инженера, — это детальное руководство по базовой репликации Redis. Благодаря ему вы сможете настроить эту СУБД на высокий уровень отказоустойчивости.
Если суперкратко:
Репликация в Redis ассинхронна.
Репликация не блокируется на стороне мастера.
Репликация (почти) не блокируется на стороне слейвов.
У мастера может быть любое количество реплик.
Каждый слейв может выступать мастером для другого инстанса.
А ещё в конце вас ждёт приятный бонус в виде разбора атаки на Redis через H2Miner, из-за которой можно полностью потерять данные на инстансе Redis
Друзья, у нас вышла заключительная часть серии «Б значит не Безумие, а Безопасность».
В финальной статье наш DevOps‑инженер Алексей покажет, как защитить ваши базы данных. В роли БД рассматривается PostgreSQL версии 14 с управлением через patroni.
Вы узнаете, как повысить скорость анализа потенциальных инцидентов, как настроить процессы шифрования дисков, как сгенерировать SSL‑сертификаты для базы данных и обеспечить их двухстороннюю проверку. А ещё познакомитесь с wal‑g-backup.