Что лучше для бизнеса: облака или 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-инфраструктура одной компании влияет на множество бизнесов? Узнаем уже завтра, 18 июля в 15:00 по Москве.
Приглашаем на вебинар, где обсудим проблемы, с которыми может столкнуться компания с устаревшей IT-инфраструктурой. Ещё поговорим про кастомизацию инфраструктуры на примере клиентского кейса из сферы FoodTech.
Каждый участник прямого эфира сможет задать свои вопросы и получить промокод на скидку на разовые работы.
Чтобы зарегистрироваться — перейдите по ссылке.
👋 До встречи!
18 июля проведём открытый вебинар «Эффект домино: как IT-инфраструктура одной компании влияет на множество бизнесов»
Когда мы особенно ярко чувствуем тесную связь разных компаний? Правильно: когда у одной из них случается сбой. Именно поэтому важно иметь надёжную IT-инфраструктуру, чтобы минимизировать проблемы не только у собственного, но и окружающего вас бизнеса.
На вебинаре:
обсудим тонкости и нюансы цифровой трансформации на примере FoodTech’а;
покажем, как справиться с нагрузками «в сезон продаж»;
разберём клиентский кейс с реальными результатами и цифрами;
ответим на все ваши вопросы;
дадим промокод на скидку в 10% на разовые работы.
Друзья! У Петра вышло продолжение серии обзорных статей про ClickHouse — open-source OLAP базу данных, ориентированную на колонки. В новой статье наш DevOps-инженер рассказывает про особенности репликации в этой СУБД.
Из этой части вы узнаете:
как работают сервисы координации Zookeeper и ClickHouse Keeper;
по какой причине может произойти падение репликации;
почему не следует очищать Keeper вручную.
Чтобы вспомнить, о чём Пётр рассказывал в первой части — нажмите сюда.
А чтобы ознакомиться с новой частью — сюда.
Всем DevOps! Однажды один из наших клиентов обнаружил, что резервные копии ClickHouse, которые он хранит в S3 провайдера CROC, не очень-то и шифруются. Была поставлена задача: настроить шифрование бэкапов.
В своей новой статье Николай, наш DevOps-инженер, показал, как мы это сделали. Он разобрал основные методы шифрования данных на стороне сервера в Amazon S3 — SSE-C, SSE-KMS и SSE-S3, расписал плюсы и минусы работы с clickhouse-backup и продемонстрировал, как легко восстановить данные из шифрованных бэкапов.
💻 Если ещё не читали, то нажмите сюда, чтобы начать.
SQL исполняется 50 лет. Сегодня вспомним историю его создания
В далёком 1970 году Эдгар «Тед» Кодд, информатик из IBM, опубликовал революционную статью под названием «A Relational Model of Data for Large Shared Data Banks», тем самым заложив основы теории реляционной модели данных.
Поначалу 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]
[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.
Если ещё не читали, то сейчас самое время;) Нажмите сюда, чтобы начать.