В OpenStack Foundation объявили, что теперь организация будет поддерживать не только открытые проекты для IaaS, но и компании, занятые разработкой решений для контейнеризации, CI/CD и периферийных вычислений.

Рассказываем, с чем связана смена направления и кто уже работает c фондом.

2017 год стал важным годом для DevOps, поскольку число игроков в экосистеме существенно выросло, а количество проектов с CNCF утроилось. Глядя на год вперед, мы ожидаем, что инновации и рыночные изменения ускорятся еще больше. Ниже мы рассмотрели тенденции в области микросервисов в 2018 году: сервисные связки(так называемые “меши”), event-driven архитектуры, нативная безопасность контейнеров, GraphQL и Chaos инженерия.

1. Сервисные связки популярны!

Сервисные связки или “меши”, выделенный уровень инфраструктуры для улучшения связи между сервисами, в настоящее время наиболее обсуждаема в контексте облачности. По мере того, как контейнеры становятся более распространенными, топологии сервисов становится все более динамичными, требуя улучшеной функциональности сети. Сервисные связки могут помочь управлять трафиком через обнаружение сервисов, маршрутизацию, балансировку нагрузки, проверку работоспособности и наблюдаемость(observability). Сервисные связки пытаются укротить непоколебимую сложность контейнера.

Очевидно, что сервисные сетки становятся все более популярными, поскольку балансировщики нагрузки, такие как HAProxy, traefik и NGINX, начали перестраиваться и представлять себя как плоскости данных(data planes). Мы пока не видели широкомасштабного развертывания, но мы знаем о компаниях, которые уже используют связки на живых серверах, в “продакшене”, так сказать. Кроме того, сервисные связки не являются эксклюзивными для микросервисов или сред Kubernetes, и также могут применяться в среде VM и без сервера. Например, в Национальном Центре Биотехнологической Информации(NCBI) нет контейнеров, но используется Linkerd.

Привет, Хабр! В данной статье я хочу поделиться опытом разворачивания тестового сервера для команды разработчиков. Вкратце суть проблемы — есть команда разработки и несколько проектов на php. Пока нас было мало и проект был по сути один, то использовался 1 тестовый сервер и чтобы показать задачу заказчику — разработчик «столбил» сервер на определенное время. Если «окон» по времени не было, то приходилось ждать. Со временем рос коллектив и сложность задач, соответственно увеличивалось время проверки и занятость тестового сервера, что негативно влияло на сроки выполнения и премию. Поэтому пришлось искать решение и оно под катом.

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

Цель данной статьи — показать простую технику настройки стенда на несколько веток. Данная статья написана разработчикам от разработчика, поэтому вряд ли будет представлять существенный интерес для профессиональных DevOps инженеров.

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

Небольшая инструкция о том, как используя Keycloak можно связать Kubernetes с вашим LDAP-сервером и настроить импорт пользователей и групп. Это позволит настраивать RBAC для ваших пользователей и использовать auth-proxy чтобы защитить Kubernetes Dashboard и другие приложения, которые не умеют производить авторизацию самостоятельно.

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

→ Часть 1: основы
→ Часть 2: термины и концепции
→ Часть 3: файлы Dockerfile
→ Часть 4: уменьшение размеров образов и ускорение их сборки
→ Часть 5: команды
→ Часть 6: работа с данными

Для того чтобы разобраться с тем, о чём мы будем тут говорить, вам будет полезно освежить в памяти то, о чём шла речь в третьей части этой серии материалов. А именно, там мы говорили об инструкциях файлов Dockerfile. Знание этих инструкций и тех особенностей Docker, которые мы обсудим сегодня, поможет вам оптимизировать файлы образов Docker.

На днях американский инженер Andrew Rynhard представил интересный проект: компактный дистрибутив Linux, предназначенный специально для запуска Kubernetes-кластеров. Он получил название из древнегреческой мифологии — Talos.

Сегодня использование цифровых сертификатов X509 v.3 стало обыденным делом. Все больше людей используют их для доступа на сайт Госуслуги, ФНС, электронные торги и т.д. И все больше людей хотят знать, что же находится в этом «сундуке» под названием сертификат. И если сертификат является аналогом паспорта, то как его можно прочитать/просмотреть. Да, в операционных системах присутствуют различные утилиты для просмотра. Но рядовому гражданину они мало что дадут. Возьмем для примера утилиту gcr-viewer, которая, по сути, является стандартным средством для просмотра в Linux-системах, а значит и в отечественных ОС:

Сколько в вашем проекте тестовых стендов — 5, 10 или больше 10? Навскидку, нужны стенды для каждой команды разработки, стенды для QA под каждый проект, менеджерам проектов тоже нужны стенды, а еще CI — трудно это все точно разграничить и не вызвать конфликтные ситуации. Одним словом, почему бы нам не делать тестовый стенд ровно тогда, когда он нужен? Нужен сейчас тестовый стенд — мы его сделали, не нужен — мы его удалили.

Именно такой подход предложил Александр Дубровин (adbrvn) на Highload++ 2017 в своем докладе, расшифровку которого вы найдете под катом.



О спикере: Александр Дубровин работает в Superjob. Известно, что проекты этой компании высоконагруженные. Но сегодня мы не будем говорить о том, сколько пользователей посещают портал, и сколько данных хранится на серверах, а затронем другие показатели.

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

Посмотрим, как использовать опубликованные в Ansible Galaxy роли (Role) в качестве операторов (Operator), управляющих приложениями в Kubernetes, и разберем это на примере создания оператора, который просто устанавливает приложение, гибко настраивая свое поведение в зависимости от среды.



Мы будем использовать Ansible Operator и модуль k8s, чтобы показать, как применять Ansible для создания Kubernetes-приложений.

Широкое использование технологий Apache-стека — очевидный тренд. И Kafka на острие популярности: нынче людей, знающих такой брокер сообщений, пожалуй, превосходит количество тех, кто привык рядом со словом Кафка видеть слово Франц.

Мы и сами активно используем эту технологию в наших проектах. Но ведь всегда интересно, а как оно получается у других? И вдвойне интересно, если это не просто пример из чьей-то практики, а целенаправленное тестирование технологии. Поэтому мы перевели свежую статью, в которой рассказывается о том, как Dropbox опытным путём искал границы возможностей и лимиты выносливости у Kafka. И нашёл что хотел.

Что мы получим после этой статьи:

Систему сбора и анализа логов на syslog-ng, elasticsearch в качестве хранилища данных, kibana и grafana в качестве систем визуализации данных, kibana для удобного поиска по логам, elasticalert для отправки уведомлений по событиям. Приготовьтесь, туториал объемный.

Какие логи будем собирать:

• все системные логи разложенные по индексам в зависимости от их facility(auth,syslog,messages и т.д.);
• логи nginx — access и error;
• логи pm2;
• и др.

Обоснование выбора системы

Почему я выбрал связку с syslog-ng в качестве отправителя, парсера и приемщика логов? Да потому что он очень быстрый, надежный, не требовательный к ресурсам(да да — logstash в качестве агентов на серверах и виртуальных машинах просто убожество в плане пожирания ресурсов и требованием java), с внятным синтаксисом конфигов(вы видели rsyslog? — это тихий ужас), с широкими возможностями — парсинг, фильтрация, большое количество хранилищ данных(postgresql,mysql,elasticsearch,files и т.д.), буферизация(upd не поддерживает буферизацию), сторонние модули и другие фишки.

Требования:

• Ubuntu 16.04 или debian 8-9;
• vm для развертывания;
• Прямые руки.

Приступим или добро пожаловать под кат

После многолетнего опыта работы с php и js, я привык иметь в ошибках стектрейс и смотреть на место, где произошла ошибка прямо из эррор-репорта. Пересев на Go пару лет назад, я был несколько удивлен, что в Go другие правила и нужно угадывать стектрейс по какой-нибудь строке типа `invalid character`. А если она произошла на проде и не известно, как ее воспроизвести, то это превращалось в целый аттракцион.

Поскольку я уверен, что не один от этого страдал, то сделал пакет, который умеет так:



→ GitHub

На примере gitlab бота я покажу, каким образом можно автоматизировать процесс релиза для serverless функций через автоматическое их обновление из git репозитория. Переходим от игр к практической разработке на serverless.

По нашей просьбе Хабр создал хаб Kubernetes и нам приятно разместить первую публикацию в нём. Подписывайтесь!

Kubernetes — это просто. Почему же банки платят мне за работу в этой сфере большие деньги, в то время как любой может освоить эту технологию буквально за несколько часов?

Прим. перев.: Оригинальную статью написал Miłosz Smółka — один из основателей небольшой польской компании Three Dots Labs, специализирующейся на «продвинутых backend-решениях». Автор опирается на свой опыт активной эксплуатации GitLab CI и делится накопленными советами для других пользователей этого Open Source-продукта. Прочитав их, мы поняли, насколько нам близки описанные им проблемы, поэтому решили поделиться предлагаемыми решениями с более широкой аудиторией.



На этот раз я затрону более продвинутые темы в GitLab CI. Частой задачей здесь является реализация в пайплайне нестандартных возможностей. Большинство советов специфичны для GitLab, хотя некоторые из них можно применить и к другим системам CI.

Билл Кеннеди в одной из лекций своего замечательного курса Ultimate Go programming сказал:

Многие разработчики стремятся оптимизировать свой код. Они берут строчку и переписывают ее, говоря, что так станет быстрее. Нужно остановиться. Говорить, что тот или иной код быстрее, можно только после того, как он отпрофилирован и сделаны бенчмарки. Гадание не является правильным подходом к написанию кода.

Мне давно хотелось на практическом примере продемонстрировать, как это может работать. И на днях мое внимание привлек следующий код, который как раз можно было бы использовать в качестве такого примера:

Эта статья содержит краткую выжимку из моего собственного опыта и опыта моих коллег, с которыми мне днями и ночами доводилось разгребать инциденты. И многих инцидентов не возникло бы никогда, если бы всеми любимые микросервисы были написаны хотя бы немного аккуратнее.

К сожалению, некоторые невысокие программисты всерьёз полагают, что Dockerfile с какой-нибудь вообще любой командой внутри — это уже сам по себе микросервис и его можно деплоить хоть сейчас. Докеры крутятся, лавешка мутится. Такой подход оборачивается проблемами начиная с падения производительности, невозможностью отладки и отказами обслуживания и заканчивая кошмарным сном под названием Data Inconsistency.

Если вы ощущаете, что пришло время запустить ещё одну аппку в Kubernetes/ECS/whatever, то мне есть чем вам возразить.

English version is also available.

Совсем недавно гитлаб героически выкатил версию 8.0 своего конкурента гитхабу. Из интересного — движок continuous integration теперь встроен в платформу, а значит доступен в качестве бесплатного сервиса для всех желающих на gitlab.com. Совместно с бесплатными приватными репозиториями это делает облачный сервис гитлаб не только удобным местом для хранения кода, но также тестирования и деплоя. О последнем я и расскажу под катом.