Совсем недавно произошёл релиз минималистичного Alpine Linux 3.8. Очень часто данный linux образ используют в докере, собирая очень компактные окружения для runtime.

Сегодняшняя статья будет рассмотрена в срезе использования runtime системы в докере для Python 3.6.X версий, с различным составом пакетов pip. А так же мы соберём самый новый Python 3.7 в Alpine.

В конце статьи будет представлен размер образа image, занимаемый на диске, в зависимости от состава пакетов pip и произведено сравнение между дистрибутивами Alpine 3.8, Debian 9, Fedora 28.

Около года мы писали об интересном онлайн-сервисе для самообразования в мире контейнеров — Play with Docker. Его авторы, поддерживаемые компанией Docker Inc, не стояли на месте и последовали за трендами, что мы наблюдаем не только в «узком кругу» Docker, но и в индустрии в целом: они запустили новый аналогичный сервис, посвящённый уже Kubernetes. Итак, встречайте Play with Kubernetes (PWK)!

Прошло уже как минимум несколько лет с тех пор, как слово «DevOps» стало у всех на слуху. Кто только не внедрял его, и чего только не делал.

Между тем, область это весьма неизведанная, таящая в себе множество открытий. Например, в русскоязычном сообществе всё еще не определились с терминологией: кто-то уже сейчас нанимает людей на должность «девопс», а кто-то всегда рассказывает, что «девопс» — это культура и практика, призванная объединить разработку, эксплуатацию и кого-то ещё, поэтому называть так должность некорректно.

Многие ищут ответ в книгах, благо в последнее время их появилось множество. Например, одними из наиболее значимых мне кажутся Devops Handbook, автором которой является наш спикер Джон Виллис, и Google SRE Book, доступная в интернете бесплатно. Однако, читая эти книги, я обнаружил следующую вещь: сухой текст не очень подходит для передачи знаний, очень сильно основанных на реальной работе живых людей. Получается слишком абстрактное знание.

Например, мы берем 14-ю главу, «Managing Incidents». Нам приводят два примера: вначале красочно рассказывается история одного инцидента, с которым разбирались неправильно. Потом рассказывается та же история, но с правильной структурой и хорошим исходом. Хороший исход наступает, если соблюдать важные практики:

Цель статьи — рассказать немного о MSBuild, показать что такое таргеты и таски в MSBuild, научить работать с файлом .csproj, дать полезные ссылки. Если у вас будет более подходящее название для статьи, то буду рад обсудить в комментариях.

Меню

• Основные понятия — что такое target и task в MSBuild
• Жизненный цикл сборки MSBuild — какая последовательность вызова таргетов
• Подготовка окружения для примеров
• Таргеты в MSBuild — пример использования некоторых таргетов MSBuild
• Создание собственного таргета MSBuild
• Таски в MSBuild — пример использования некоторых тасков MSBuild
• Переменные и макросы в .csproj
• Ссылки

Прим. перев.: Мы уже не раз писали о containerd и других исполняемых средах для Kubernetes. Новая публикация — перевод недавнего анонса важной вехи в развитии containerd, опубликованного в официальном блоге проекта Kubernetes. Текст написан сотрудниками компаний Google и IBM, которые (конечно, вместе с Docker Inc) вносят значительный вклад в совершенствование containerd.

Ранее в блоге — в заметке Containerd Brings More Container Runtime Options for Kubernetes — мы представляли альфа-версию интеграции containerd с Kubernetes. Очередные 6 месяцев разработки привели к тому, что интеграция стала общедоступной! Это означает, что теперь вы можете использовать containerd 1.1 в качестве исполняемой среды для контейнеров в Kubernetes-кластерах в production.

Containerd 1.1 работает с Kubernetes версии 1.10 и выше, поддерживает все возможности Kubernetes. В инфраструктуре тестов Kubernetes покрытие тестами интеграции с containerd на Google Cloud Platform стало таким же, что и у интеграции с Docker (см. test dashboard).

Интервью с Александром Титовым, одним из членов программного комитета нашей июньской конференции HighLoad++, отдельная секция которой будет посвящена DevOps.
Под катом про то, в каком направлении дует «ветер» DevOps, и какие именно аспекты этой концепции будут обсуждаться на форуме.

Админ — это тот человек, без которого ничего в ИТ-компании не заработает. А со счастливым и продуктивным админом, дело будет двигаться лучше и быстрее, поэтому комфортная рабочая атмосфера — забота компании. О том, с помощью каких инструментов сделать команду продуктивной, был доклад Антона Турецкого (banuchka) на Highload++ 2017.

Антон любит инфраструктурные задачи и автоматизацию всего, что можно автоматизировать, поэтому его рассказ основан на примере настройки инфраструктуры в дата-центре и сопутствующих технологиях (Docker, Consul, Puppet...). Но аспекты, мешающие качественной работе и способы их решения максимально универсальны и подходят практически для любой исполнительной команды. Так что милости просим под кат за расшифровкой этого доклада.



Badoo с каждым годом растет, вот несколько чисел, которые это отражают: 350 млн сообщений в сутки, 364 млн зарегистрированных пользователей по всему миру, 300 тысяч новых пользователей в день. Но это далеко не самое главное, для человека, который в Badoo работает, главное — это в первую очередь образ мышления и команда. Badoo — это семья, это про людей и это круто!

Хочу начать с провокации, которую, возможно, кто-то не поддержит:

Админ — это главный человек в компании!

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

Книга рассказывает, как выстроить тестирование, чтобы не просто вылавливать баги, а избежать их появления. Она нам очень понравилась, так что мы решили на правах старожилов поддержать традицию конспектов на Хабре и выложить самые интересные тезисы.

Прим. перев.: Автор этого материала — архитектор в Barclays и Open Source-энтузиаст из Великобритании Ian Miell. Он задаётся целью сделать удобный образ Docker (со «спящим» бинарником), который не нужно скачивать, а достаточно просто копировать через copy & paste. Методом проб, ошибок и экспериментов с Assembler-кодом он достигает цели, подготовив образ размером менее килобайта.

Как я к этому пришёл?

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

28 мая на проходившей в рамках фестиваля РИТ++ 2018 конференции RootConf 2018, в секции «Логирование и мониторинг», прозвучал доклад «Мониторинг и Kubernetes». В нём рассказывается об опыте настройки мониторинга с Prometheus, который был получен компанией «Флант» в результате эксплуатации десятков проектов на Kubernetes в production.



По традиции рады представить видео с докладом (около часа, гораздо информативнее статьи) и основную выжимку в текстовом виде. Поехали!

Чтобы ничего не знать о Kubernetes, надо было последние три года прожить в пещере. В Handy инфраструктура разработки, CI/CD и продакшена построена на многокластерной экосистеме Kubernetes. Можно сказать, что мы в Handy фанаты Kubernetes, вот почему мы так удивились, когда личный кластер Kubernetes нашего коллеги в прошлые выходные взломали.

Удивились — и обрадовались, так как обнаружили в Kubernetes один малоизвестный глюк. В этой статье мы рассмотрим, как был взломан кластер коллеги и как мы подтвердили свои выводы, воссоздав эту атаку в собственном кластере. Атака была протестирована в Kubernetes 1.9, но может работать и на более старых кластерах.

ДИСКЛЕЙМЕР: эта статья о личном сервере нашего коллеги. Инфраструктура Handy Technologies не была скромпрометирована.

Микрозаметка о том, как запустить Docker с Systemd внутри Gitlab CI Runner'a. Возможно кому-то будет полезна, возможно кто-то решал уже подобную задачу другими способами и будет интересно если поделитесь в комментариях.

Minishift – это инструмент, который позволяет вам запустить OpenShift локально как кластер OpenShift из одного узла внутри виртуальной машины.

Технологии развиваются, и вместе с ними меняются и процессы разработки и развертывания приложений. Если раньше это были достаточно стандартные вещи со строго ограниченным набором задействованных компонентов, то в последние годы с появлением новых инструментов и фреймворков в этой области произошли резкие перемены. Установка пакета ПО на личный компьютер сегодня выглядит тривиальной, но поставьте себя на место ИТ-отдела, и сразу возникнет масса вопросов. Откуда взялся тот или иной программный компонент? Зачем он нужен? Как он обновляется? Кто осуществляет его поддержку? Эти действительно важные и неизбежные вопросы, если организация придерживается передовых методик обеспечения безопасности и должна соответствовать политикам и правилам безопасности.



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

Все уже, наверное, в курсе про такую организацию как Let’s Encrypt. С некоторых пор там можно получить и wildcard сертификат. В этой короткой заметке я опишу пару не очень очевидных моментов, с которыми столкнулся.

Привет, Хабр. На прошедшей BackendConf Антон Олиевский, наш руководитель отдела тестирования и контроля качества программного обеспечения, рассказал про самое, пожалуй, важное — осознанное отношение к работе.

Майкл ДеХаан – человек, который создал Ansible. Многие вещи, которые делают системные администраторы, релиз- и DevOps-инженеры на регулярной основе, мягко говоря, неинтересны. ДеХаан хочет, чтобы эти люди освободили свое время для более интересных вещей (на работе или за дверью офиса), и написал код продукта, который освобождает время администратора.
Больше времени, меньше адреналина в рабочие часы, меньше скриптов и меньше ошибок.
Кстати, вы можете закончить чтение на этом абзаце, вместо этого подключившись к livestream 6 июня вот здесь.

Этот материал продолжает цикл о сборке Docker-образов для приложений на различных языках программирования с помощью утилиты dapp. Предыдущая статья была о сборке приложений на Java — теперь же поговорим о приложениях на JavaScript. Для начала это будет frontend-приложение, а в следующей части планируется рассказать о сборке backend'а и запуске всего в Kubernetes.

Обновлено 13 августа 2019 г.: в настоящее время проект dapp переименован в werf, его код переписан на Go, а документация значительно улучшена.

В качестве иллюстрации будут использованы приложения nodejs-pool и poolui. Да-да, подготовим к запуску в Kubernetes свой майнинг-пул с блокчейном и выплатами!

Прим. перев.: В этой статье, написанной техническим консультантом и сертифицированным администратором Kubernetes из Великобритании — Daniele Polencic, — наглядно показывается и рассказывается о том, какую роль играет kube-proxy в доставке пользовательских запросов до подов и что происходит, когда на одном из узлов кластера возникают проблемы.

Код приложений, развёрнутых в Kubernetes, запускается на одном или более рабочих узлов. Узел может располагаться как на физической или виртуальной машине, так и в AWS EC2 или Google Compute Engine, а наличие множества таких площадок означает возможность эффективного запуска и масштабирования приложения. Например, если кластер состоит из трёх узлов и вы решаете отмасштабировать приложение на четыре реплики, Kubernetes равномерно распределит их среди узлов следующим образом:

Действующие лица (Команда): разработчиков – 2 человека, админ – 1 человек.

Статья повествует об использовании таких технологий, как Ansible, Docker Swarm, Jenkins и Portainer для реализации CI/CD-пайплайна с возможностью контроля за ним с помощью красивого веб-интерфейса.

Вступление

Чего обычно хочет разработчик? Он хочет творить, не думая о деньгах, и максимально быстро видеть результаты собственного творчества.

С другой стороны, есть бизнес, который хочет денег, да побольше, и поэтому постоянно думает о снижении времени вывода продукта на рынок. Другими словами, бизнес мечтает об ускорении получения MVP (a.k.a. Minimum Viable Product) в новых продуктах или при обновлении существующих.

Ну а чего же хочет админ? А админ – человек простой, он хочет, чтобы сервис не падал и не мешал играть в Кваку Танки и чтобы его пореже дергали разработчики и бизнес.
Поскольку для реализации желаний админа, как показывает правда жизни, его силами должны реализоваться и мечты других героев, представители ИТ-тусовки много работали над этим. Часто получалось достичь желаемого, придерживаясь методологии DevOps и реализуя принципы CI/CD (Continuous Integration and Delivery).

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