DevOps *

Нас все чаще спрашивают про разработку микросервисов в Kubernetes. Разработчики, особенно интерпретируемых языков, хотят быстро поправить код в любимой IDE и без ожидания сборки/деплоя увидеть результат — по простому нажатию на F5. И когда речь шла про монолитное приложение, достаточно было локально поднять базу данных и веб-сервер (в Docker, VirtualBox…), после чего — сразу же наслаждаться разработкой. С распиливанием монолитов на микросервисы и приходом Kubernetes, с появлением зависимостей друг от друга, всё стало немного сложнее. Чем больше этих микросервисов, тем больше проблем. Чтобы вновь насладиться разработкой, нужно поднять уже не один и не два Docker-контейнера, а иногда — даже не один десяток… В общем, на всё это может уходить достаточно много времени, поскольку требуется ещё и поддерживать в актуальном состоянии.

Всем привет!

Ооочень хочется прям сразу приступить к теме, но правильнее будет немного рассказать про мою историю:

Вступление

Я программист с опытом разработки frontend одностраничных приложений, scala/java и nodejs на сервере.

Довольно долго (уже точно пару — тройку лет), я придерживался мнения, что docker это манна небесная и вообще очень крутой инструмент и абсолютно каждый разработчик должен уметь пользоваться им. А отсюда вытекает, что и у каждого разработчика должен стоять docker на локальной машине. Да что там про моё мнение, вы полистайте вакансии, которые размещаются на том же hh. В каждой второй есть упоминание про docker и если вы им владеете — это будет вашим конкурентным преимуществом ;)

На своем пути я встечался с многими людьми, с их разным отношением к docker и к его экосистеме. Одни говорили, что это удобная вещь, гарантирующая кроссплатформенность. Вторые не понимали зачем им запускаться в контейнерах и какой профит от этого, третьим было вообще пофиг и они не парились (просто писали код и уходили домой — завидую, кстати, им :) )

Наш гость, создатель инструментов для разработчиков из Pantheon, рассказывает, как автоматизировать деплои WordPress с помощью GitLab CI/CD.

В Pantheon я занимаюсь связями с разработчиками, поэтому всегда ищу новые способы помочь разработчикам WordPress и Drupal решать проблемы с автоматизацией в рабочих процессах. Для этого я люблю экспериментировать с новыми инструментами и сочетать их друг с другом для эффективной работы.

Я часто вижу, как разработчики мучаются с одним сервером для разработки.

Так себе удовольствие — ждать своей очереди использовать сервер или отправлять клиентам URL с пометкой: «Вот здесь смотреть, а здесь пока не смотреть».

Среды multidev — один из крутых инструментов Pantheon — решают эту проблему, ведь с ними можно по запросу создавать среды под ветки Git. У каждой среды multidev свой URL и база данных, поэтому разработчики спокойно работают, проверяют качество и получают одобрение, не наступая друг другу на пятки.

Но в Pantheon нет инструментов для контроля версий или непрерывной интеграции и деплоя (CI/CD). Зато это гибкая платформа, с которой можно интегрировать любые инструменты.

Еще я заметил, что для разработки команды используют одни инструменты, а для сборки и деплоя — другие.

Например, у них разные инструменты для контроля версий и CI/CD. Приходится возиться и переключаться между инструментами, чтобы редактировать код и диагностировать проблемы.

Эта статья является пятой в цикле статей «Как взять сетевую инфраструктуру под свой контроль». Содержание всех статей цикла и ссылки можно найти здесь.

Эта часть будет посвящена аудиту security дизайна Campus (Office) & Remote access VPN сегментов.



Может показаться, что дизайн офисной сети – это просто.

Действительно, берем L2/L3 коммутаторы, соединяем их между собой. Далее, производим элементарную настройку виланов, шлюзов по умолчанию, поднимаем простой роутинг, подключаем WiFi контроллеры, точки доступа, устанавливаем и настраиваем ASA для удаленного доступа, радуемся, что все заработало. В принципе, как я уже писал в одной из предыдущих статей этого цикла, спроектировать и настроить офисную сеть, чтобы «как-то работало», может почти каждый студент, прослушавший (и усвоивший) два семестра курса по телекому.

Но чем больше вы узнаете, тем менее элементарной начинает казаться эта задача. Лично для меня эта тема, тема дизайна офисной сети, совсем не кажется простой, и в этой статье я постараюсь объяснить почему.

Если коротко, то нужно учитывать довольно много факторов. Часто эти факторы находятся в противоречии друг с другом и приходится искать разумный компромисс.
Вот эта неопределенность и является основной сложностью. Так, говоря про безопасность, мы имеем треугольник с тремя вершинами: безопасность, удобство для сотрудников, цена решения.
И каждый раз приходится искать компромисс между этими тремя.

Мы в True Engineering настроили процесс непрерывной доставки обновлений на сервера заказчика и хотим поделиться этим опытом.

Для начала мы разработали онлайн систему для заказчика и развернули её в собственном кластере Kubernetes. Теперь наше высоконагруженное решение переехало на платформу заказчика, для чего мы настроили полностью автоматический процесс Continuous Deployment. Благодаря этому, мы ускорили time-to-market – доставку изменений в продуктовую среду.

В этой статье мы расскажем обо всех этапах процесса Continuous Deployment (CD) или доставки обновлений на платформу заказчика:

1. как стартует этот процесс,
2. синхронизация с Git-репозиторием заказчика,
3. сборка бекенда и фронтенда,
4. автоматическое развертывание приложения в тестовой среде,
5. автоматическое развертывание на Prod.

В процессе поделимся деталями настройки.

Цель статьи — на примере библиотеки schema-keeper показать инструменты для упрощения разработки баз данных в PHP-проектах, использующих СУБД PostgreSQL.

Будут рассмотрены следующие вопросы:

1. В каком виде хранить дамп структуры БД в системе контроля версий (далее по тексту — VCS)
2. Как отслеживать изменения в структуре БД после сохранения дампа
3. Как переносить изменения в структуре БД на другие окружения без конфликтов и гигантских файлов миграций
4. Как наладить процесс параллельной работы над проектом нескольких разработчиков
5. Как безопасно деплоить большее количество изменений в структуре БД на production-окружение

Информация из этой статьи, в первую очередь, будет полезна разработчикам, которые по максимуму хотят использовать возможности PostgreSQL, но сталкиваются с проблемами сопровождения бизнес-логики, вынесенной в БД.

Статья не будет описывать преимущества или недостатки хранения бизнес-логики в базе данных. Предполагается, что выбор уже сделан читателем.

Хотелось бы рассказать один интересный механизм работы с конфигурацией распределённой системы. Конфигурация представлена напрямую в компилируемом языке (Scala) с использованием безопасных типов. В этом посте разобран пример такой конфигурации и рассмотрены различные аспекты внедрения компилируемой конфигурации в общий процесс разработки.

(english)

Splunk является одним из нескольких наиболее узнаваемых коммерческих продуктов для сбора и анализа логов. Даже сейчас, когда продажи в России больше не производятся, это не повод не писать инструкции/how-to по этому продукту.

В нашем блоге уже были статьи, рассказывающие про возможности операторов в Kubernetes и о том, как написать простой оператор самому. На этот раз хотим представить вашему вниманию наше Open Source-решение, которое выводит создание операторов на суперлёгкий уровень, — познакомьтесь с shell-operator!

Зачем?

Идея shell-operator довольно проста: подписаться на события от объектов Kubernetes, а при получении этих событий запустить внешнюю программу, предоставив ей информацию о событии:

При запуске кластера Kubernetes для конкретного приложения следует понимать, какие требования представляет к этому ресурсу само приложение, бизнес и разработчики. При наличии этой информации можно приступать к принятию архитектурного решения и, в частности, к выбору конкретного Ingress-контроллера, коих на сегодняшний день уже большое количество. Чтобы составить базовое представление об имеющихся вариантах без необходимости изучать множество статей/документации и т.п., мы и подготовили этот обзор, включив в него основные (production ready) Ingress-контроллеры.

Надеемся, что он поможет коллегам в выборе архитектурного решения — по крайней мере, станет отправной точкой для получения более подробной информации и практических экспериментов. Предварительно мы изучили другие подобные материалы в сети и, как ни странно, не обнаружили ни одного более-менее полного, а главное — структурированного — обзора. Итак, заполним же этот пробел!

Я создал Kube Eagle — экспортер Prometheus. Оказалось, крутая штука, которая помогает лучше разбираться в ресурсах маленьких и средних кластеров. В итоге я сэкономил не одну сотню долларов, потому что подбирал правильные типы машин и настраивал ограничения ресурсов приложений под рабочие нагрузки.

Я расскажу о преимуществах Kube Eagle, но сначала объясню, из-за чего вышел сыр-бор и для чего понадобился качественный мониторинг.

Данная статья о том как настроить современный почтовый сервер.
Postfix + Dovecot. SPF + DKIM + rDNS. С IPv6.
С шифрованием TLS. С поддержкой нескольких доменов — часть с настоящим SSL сертификатом.
С антиспам-защитой и высоким антиспам-рейтингом у других почтовых серверов.
С поддержкой нескольких физических интерфейсов.
С OpenVPN, подключение к которому через IPv4, и которое даёт IPv6.

Если вы не хотите изучать эти все технологии, но хотите настроить такой сервер — тогда эта статья для вас.

В статье отсутствуют попытки пояснить каждую деталь. Пояснение идёт к тому, что настроено не стандартно или важно с точки зрения потребителя.

Оглавление для всех статей цикла «Как взять сетевую инфраструктуру под свой контроль» и ссылки.

На данный момент опубликовано 7 статей:

Глава 1. Удержание
Глава 2. Чистка и документирование
Глава 3. Сетевая безопасность. Часть первая
Глава 3. Сетевая безопасность. Часть вторая
Глава 3. Сетевая безопасность. Часть третья
Глава 4. Автоматизация. Темплейты

Дополнение. О трех компонентах необходимых для успешной работы IT

Всего будет порядка 10 статей.

В наших проектах мы используем микросервисную архитектуру. При возникновении узких мест в производительности достаточно много времени тратится на мониторинг и разбор логов. При логировании таймингов отдельных операций в лог-файл, как правило, сложно понять что привело к вызову этих операций, отследить последовательность действий или смещение во времени одной операции относительно другой в разных сервисах.

Для минимизации ручного труда мы решили воспользоваться одним из инструментов трассировки. О том, как и для чего можно использовать трассировку и как это делали мы, и пойдет речь в этой статье.

В современных ЦП очень много ядер. Годами приложения посылали запросы в базы данных параллельно. Если это отчетный запрос ко множеству строк в таблице, он выполняется быстрее, когда задействует несколько ЦП, и в PostgreSQL это возможно, начиная с версии 9.6.

Понадобилось 3 года, чтобы реализовать функцию параллельных запросов — пришлось переписать код на разных этапах выполнения запросов. В PostgreSQL 9.6 появилась инфраструктура для дальнейшего улучшения кода. В последующих версиях и другие типы запросов выполняются параллельно.

В данной статье я хочу рассказать про две возможности NGINX Ingress, связанные с отображением персонализированных страниц с ошибками, а также о существующих в них ограничениях и способах их обойти.

Прим. перев.: Первая часть этого цикла была посвящена знакомству с возможностями Istio и их демонстрации в действии, вторая — тонко настраиваемой маршрутизации и управлению сетевым трафиком. Теперь же речь пойдёт про безопасность: для демонстрации связанных с ней базовых функций автор использует identity-сервис Auth0, однако по аналогии с ним могут настраиваться и другие провайдеры.

Мы настроили Kubernetes-кластер, в котором развернули Istio и пример микросервисного приложения Sentiment Analysis, — так были продемонстрированы возможности Istio.

С помощью Istio нам удалось сохранить небольшой размер сервисов, поскольку они не нуждаются в реализации таких «слоёв», как повторные попытки подключения (Retries), таймауты (Timeouts), автоматический выключатели (Circuit Breakers), трассировка (Tracing), мониторинг (Monitoring). Кроме того, мы задействовали техники продвинутого тестирования и деплоя: A/B-тестирование, зеркалирование и канареечные выкаты.

Быстрое обнаружение утечки секретов

Казалось бы, небольшая ошибка — случайно передать учетные данные в общий репозиторий. Однако последствия могут быть серьезные. Как только злоумышленник получит ваш пароль или API-ключ, он захватит вашу учетную запись, заблокирует вас и обманным путем использует деньги. Кроме того, возможен эффект домино: доступ к одной учетной записи открывает доступ к другим. Ставки высоки, поэтому чрезвычайно важно узнавать об утечке секретов как можно скорее.

В этом релизе мы представляем опцию обнаружения секретов в рамках нашего функционала SAST. Каждый коммит сканируется в задании CI/CD на наличие секретов. Есть секрет — и разработчик получает предупреждение в мердж-реквесте. Он на месте аннулирует утекшие учетные данные и создает новые.

Это первая из серии наших публикаций, посвященных улучшениям и дополнениям в грядущем обновлении платформы Red Hat OpenShift до версии 4.0, которая поможет вам подготовиться к переходу на новую версию.



Какие инструменты вы сможете получить в свое распоряжение, чтобы создавать более качественные программные продукты, и как они позволят повысить безопасность и сделать разработку проще и надежнее?

База данных временных рядов (TSDB, time series database) в Prometheus 2 – это отличный пример инженерного решения, которое предлагает серьёзные улучшения в сравнении с хранилищем v2 в Prometheus 1 в плане скорости накопления данных и выполнения запросов, эффективности использования ресурсов. Мы внедряли Prometheus 2 в Percona Monitoring and Management (PMM), и у меня была возможность разобраться с производительностью Prometheus 2 TSDB. В этой статье я расскажу о результатах этих наблюдений.