DevOps *

Если вы работаете с быстрорастущим проектом, то знаете, что он требует управляемой ИТ-инфраструктуры. Все время приходится поднимать тестовые хосты, постоянно что-то разворачивать, обновлять исходники, добавлять ресурсы и распределять нагрузку. Все это — рутинные задачи DevOps-специалиста, а если не повезло, то самого разработчика.

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

Привет, Хабр! Меня зовут Дмитрий Самсонов, я работаю ведущим системным администратором в Одноклассниках. Основные сферы моей компетенции — Zabbix, CFEngine и оптимизация Linux. У нас более 8 тыс. серверов и 200 приложений, которые в различной конфигурации формируют 700 различных кластеров. Тема этой статьи исчерпывающе описана в заголовке.

Сразу хочу оговориться:

• Я буду предвзят, потому что участвовал во внедрении CFEngine в Одноклассниках.
• Я пользовался CFEngine только версий 3.3—3.4.
• Я не питаю никаких иллюзий по поводу CFEngine, это значимый игрок, но не лидер рынка и не его аутсайдер. В статье не будет сравнений работы CFEngine с другими системами.
• Из систем конфигурации у меня есть опыт использования только CFEngine и Ansible.

Прим. перев.: Этот материал, озаглавленный в оригинале как «What happens when… Kubernetes edition!» и написанный Jamie Hannaford из компании Rackspace, является отличной иллюстрацией работы многих механизмов Kubernetes, которые зачастую скрыты от нашего глаза, но весьма полезны для лучшего понимания устройства этой Open Source-системы, алгоритма работы и взаимосвязей её компонентов. Поскольку вся статья весьма объёмна, её перевод разбит на две части. В первой речь идёт про работу kubectl, kube-apiserver, etcd и initializers.

P.S. Некоторые оригинальные ссылки на код в master-ветках были заменены на последние к моменту перевода коммиты, чтобы актуальность номеров строк, к которым отсылает автор, сохранялась долгое время.



Представим, что я хочу задеплоить nginx в кластере Kubernetes. Я введу в терминале нечто такое:

kubectl run --image=nginx --replicas=3

… и нажму на Enter. Через несколько секунд увижу 3 пода с nginx, распределённые по всем рабочим узлам. Работает — словно по волшебству, и это здорово! Но что на самом деле происходит под капотом?

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

Поехали…

Работая вместе с соавторами над DevOps Cookbook, я начал лучше понимать, что является основным акцентом DevOps сообщества. Много внимания уделяется влиянию DevOps в рамках ИТ-подразделения. Гораздо меньше внимания уделяется влиянию DevOps в рамках всей компании. И практически никакого внимания не уделяется влиянию DevOps вне рамок компании, в частности взаимоотношению с другими компаниями и рынками, на которых они конкурируют.

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

Но если ограничить DevOps евангелизм только ИТ организациями, будет упущена ценная польза от инвестиций в DevOps. Почему? Потому что уроки и принципы DevOps открывают нечто редкое для современных компаний. DevOps может превратить ИТ-процессы в устойчивое конкурентное преимущество компании. Это DevOps-послание необходимо распространить по всему бизнес отделу компании, вплоть до Генерального Директора и Совета Директоров.

Чтобы понять, как DevOps может превратить ИТ-процессы в конкурентное преимущество, сначала нужно взглянуть на текущий контекст, в котором работают компании.

Недавно вышла статья Iron_Butterfly, где в числе прочего, рассказывается, каким образом можно запустить мощнейший поисковый движок ElasticSearch внутри Docker-контейнера. Я хочу продолжить этот вектор и рассказать, какие еще задачи можно решить с помощью Docker-контейнеров, используя для этого Plesk и расширение Docker.

Краткий план

В статье мы рассмотрим, как с помощью помощью Docker extension можно решить задачи, которые тяжело или даже невозможно решить с Plesk без Docker-контейнеров. Данный список задач сформирован на основе популярных вопросов наших пользователей; в качестве пользователей мы рассмотрим владельцев хостинга, разработчиков web-приложений, администраторов WordPress.

Задачи:

— Одновременное использование различных версий баз данных;
— Разворачивание Memcached для WordPress;
— Использование собственного облачного Nextcloud хранилища;
— Запуск собственного приложения на Go. Запуск собственного git-репозитория;
— Тестирование новых версий Plesk не мешая работать боевому серверу.

Хочу уточнить, что все примеры в статье выполнены с использованием бесплатной версии расширения Docker; платная версия позволяет управлять сервисом Docker на удаленных серверах.

TL;DR: автор сокрушается о том, что GRUB не может жить полноценно с LVM и с удивлением открывает, что это отлично умеет заброшенный в 2015 году загрузчик lilo.

MBR?

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

Я еще раз повторю, не надо сейчас мне говорить «так сложилось», а включите логику. MBR ужасна.

Цикл историй успеха Kubernetes продолжается рассказом о британском банке-стартапе Monzo. Эту молодую компанию относят к категории «challenger banks» (да, это уже термин из Oxford Dictionary), т.е. таких небольших банков, которые бросают вызов крупной и давно сложившейся финансовой индустрии. Это становится возможным благодаря активному и повсеместному использованию современных информационных технологий в самой своей основе, т.е. отказу от операций в традиционном формате в пользу электронных аналогов, позволяющих качественно снизить расходы (банки с таким подходом ещё называют «digital-only»). Пример Monzo, созданного всего 2 года назад, интересен тем, что в достижении великих целей ему помогают платформа Kubernetes, язык Go и другие современные Open Source-продукты, хорошо знакомые DevOps-инженерам и не только.

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

Добавление новых плагинов происходит постоянно, если вас заинтересовал проект, вы можете легко и просто добавить свои плагины, поделившись полезными скриптами с сообществом.

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

Кому, как мне кажется, данная статья может оказаться полезной:

• ваши проекты содержат несколько отдельных репозиториев с приложениями;
• вы хотите быть уверены, что каждый репозиторий проходит тесты;
• вы хотите быть уверены в совместимости версий между репозиториями;
• вы ещё не успели, но планируете, перевести свои проекты на докер;
• хотите посмотреть пару playbook'ов Ansible.

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

В одном из предыдущих постов про DevOps мы обещали рассказать про технологическую составляющую нашего CI/CD-конвейера.

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

Доброго времени суток!

Сегодня будем готовить Puppet 4 на Ubuntu Server 16.04 c хранением манифестов в SVN. Так же статье будет рассмотрен пример создания простого собственного модуля для установки и конфигурирования агента сбора логов в Graylog2 через Graylog Collector Sidecar и использованием Filebeat в качестве бэкэнда. Данный пример не претендует на изящное решение, но описывает ключевые аспекты с примером.

Исходная машина для Puppet Server — VPS Ubuntu 16.04 — 4Gb Memory, 2 CPU cores.

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

Я хочу поделиться с вами историей, как мы строили CI/CD-процессы для ПО, написанного для нестандартной платформы, которую многие считают «динозавром» — IBM System i aka AS/400.


AS/400 используется многими крупными российскими банками, и все они потихоньку движутся в направлении CI/CD. Райффайзенбанк стал одними из первых (если не первым), кто применил эти практики для установки ПО на платформе AS/400 в промышленной эксплуатации.


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

Доброго всем. Делимся тут очень интересной статьёй, на которую натыкались в рамках подготовки нашего курса. Перевод идёт, как есть целиком (за исключением некоторых комментариев).

Предыстория

В двух словах — вступление о мониторинге и аппеляционности убеждений. Как многим известно, я сопровождаю Riemann — инструмент обработки потоков событий для мониторинга распределенных систем. В моей книге, посвященной мониторингу, я использовал Riemann, как основной инструмент для изучения новых подходов и паттернов мониторинга, и описал архитектуру whitebox-мониторинга (с выборочным blackbox-мониторингом), используя push модель.

Чтобы понять, о чем я вообще веду речь, объясним некоторые концепции. Blackbox-мониторинг отвечает за проверку внешних характеристик сервисов или приложений: возможно ли подключиться к открытому порту сервиса, возвращаются ли корректные данные или код ответа. Примером blackbox-мониторинга может служить ICMP-запрос и подтверждение получения ответа.

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

Kubectl — основной консольный интерфейс для взаимодействия с Kubernetes и, безусловно, важный инструмент в руках любого администратора/DevOps-инженера, причастного к эксплуатации таких кластеров. Если вы пользуетесь им каждый день и делаете это по-настоящему активно, то, как это свойственно ИТ-специалистам, наверняка задумывались о способах упрощения/автоматизации своих манипуляций. Благо, это мир сисадминов, Open Source и консоли, так что в нём, конечно, уже нашлись и те, кто не только задумывался об этом, но и воплотил свои потребности в жизнь — в виде утилит, доступных теперь и всем «коллегам по цеху». О них и пойдёт речь в этом небольшом обзоре.

Привет, Хабр!

Некоторое время мы присматриваемся к книгам по Kubernetes, благо, они уже выходят и в Manning, и в O'Reilly. Можно согласиться, что Kubernetes в наших краях пока интересен скорее с ознакомительной и инженерной, нежели с практической точки зрения. Однако, мы все-таки поставим здесь обложку с книги о Kubernetes и перевод статьи Дэниэла Морсинга, который сделал у себя в блоге интересный тизер об этой системе.

Приятного чтения!

Когда мы опубликовали первую статью по теме DevOps в ЕФС, нас спросили, почему в ней нет ни слова о культуре процесса. Ведь в первую очередь DevOps — это IT-партнерство, более высокая стадия эволюции инженерной культуры, а только потом — автоматизация. В этой статье мы расскажем, как меняли мировоззрение сотрудников и что открыли для себя в этой области.

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

Так родился проект loghouse, и я рад представить его альфа-версию DevOps-инженерам и системным администраторам, которым знакомы обозначенные проблемы.