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

Как и упоминал ранее, статья по взаимодействию Jenkins с Docker. В этот раз рассмотрим основные способы (только способы, без раскрытия темы на предмет того, как правильно), с помощью которых можно выстроить процесс CI в Jenkins, в сочетании с использованием контейнеров на базе Docker.

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

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

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

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

Именно эта подчасть осталась практически неизменной, в сравнении с её первоначальным видом, за исключением некоторых погрешностей, которые были исправлены.

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

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

В обозримом будущем продолжу перевыпуск статей по Docker, поскольку есть что добавить. К тому же по Jenkins я рассказал почти всё, что планировал, а на статьи, подобно этой или прошлой, нужно гораздо больше времени, так как я уже начинаю писать не просто про Jenkins, а ещё и про сторонние технологии, которые учавствуют в симбиозе с самим Jenkins. Это, в свою очередь, требует больше времени. Хотя идей на ещё штук 10 найдется, так что скучать не придется.

Возвращаясь к «ремастеру» по Docker в этой статье затронем тему томов в целом, и как с ними работать в частности. В общем всё по аналогии с сетями. Только в этот раз я немного дополнил содержимое информацией по UFS, а также исправил существующие неточности.

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

Вот и вторая часть по сборке собственных образов в Docker. В этот раз речь пойдет о том, как правильно организовать многоэтапную сборку приложения. Так же, в некотором роде, эту статью можно считать прямым продолжением вот этой, в которой речь шла о томах в Docker. Это потому, что, хоть и косвенно, но здесь, в том числе, разговор пойдет о теме UFS, слоёв и т.д.

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

Собственно, вот -- https://github.com/exitfound/faj. Умеет разворачивать Jenkins в Docker с помощью Compose (как об этом было рассказано в этой статье), а конфигурацию брать из файлов, описанных в стиле CasC. Есть также возможность развёртывания через Ansible для более матёрых (там же есть и вспомогательные роли). Ещё, не без помощи других, написал скрипт на Bash, который достаточно удобно, используя API Jenkins, экспортирует / импортирует джобы со старого на новый Jenkins. В README можно узнать побольше обо всём этом. Проект планирую поддерживать и дорабатывать в будущем.

Немного затянул с публикацией. Никак не мог собраться и закончить начатое. В общем очередная повесть о том, как мы Jenkins познаём. В этот раз речь пойдет о том, как можно более-менее безболезненно выгрузить данные из старого Jenkins и передать их на новый. В основном всё крутится вокруг заданий (Jobs), но в конце статьи и до полноценного резервирования данных дойдем. Хотя, как и всегда, телеграф угнетает по числу символов и не даёт развернуться в полной мере, поэтому только краткая выжимка.

В этот раз рассмотрим ещё одну, но уже последнюю крупную тему в контексте статей по Docker – она же безопасность. Данная тема, как и предыдущие, также будет разбита на несколько подчастей, которые будут взаимосвязаны друг с другом. Сначала побудем на стороне защищающегося, а после – на стороне атакующего. Конкретно в этой подчасти пройдемся по теме привилегированного пользователя, взаимодействию с сокетами, профилям Seccomp и AppArmor, и т.д. Никакой глубины, поскольку я не считаю себя специалистом по безопасности. Сугубо краткая выжимка с общими тезисами, которые собраны в одном месте.

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

Этой статьей я закрываю как тему безопасности в частности, так и цикл статей по Docker в целом. Разумеется, что в будущем мы ещё не раз будем к нему возвращаться, однако это уже не будет детальный разбор особенностей самого Docker. Что касается данной подчасти, то она была переделана гораздо сильнее, чем все предыдущие, посколько спустя время область применения несколько изменилась. Хотя затрагиваемые темы остались те же – это атака на сокет Docker и различные PoC в контексте Cgroups.

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

Так-с. На какое-то время потерял вдохновение, но всех живых и оставшихся приветствую новой статьей на тему Vault. В этот раз рассмотрим как взаимодействовать с такой подсистемой секретов, как KV (она же key=value). Немного теории, а после демонстрация того, как со всем этим работать и через консоль, и через Web-панель Vault.

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

Вот и третья по счету статья на тему Vault. Изначально я хотел описать методы аутентификации и применяемые политики в рамках этой самой аутентификации, но материала оказалось больше, чем я предполагал, поэтому в этой части речь пойдет сугубо о базовых методах аутентификации в Vault средствами самого Vault (то бишь, без привязки к AWS, GitHub и т.д). А уже в следующей части мы более предметно поговорим о настраиваемых политиках в Vault.

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

Приветствую всех тех, кто пришёл от @SysadminNotes и не только. В первую очередь хотелось бы поблагодарить Артема за то, что упомянул мой маленький канал.

Так как людей стало чуть больше, наверное стоит вкратце разъяснить, как этот канал живет что ли, ибо на первый взгляд не очень очевидно и некоторым это может не подойти. Изначально я задумывал его создание специально под Linux на базе OpenSUSE, поскольку мне этот дистрибутив очень нравится и я пользуюсь, по возможности, именно им. Однако в сети не то чтобы очень много статей по нему есть, особенно когда речь касается таких моментов, когда у OpenSUSE идёт расхождение с Fedora, CentOS и т.д. Собственно, это всё. И по началу статьи таки были в этом направлении, но спустя какое-то время меня занесло на дорожку DevOps'а и как-то времени уже разбираться не было, особенно когда профита с этого стало сильно меньше, так как здесь и сейчас подавай контейнеры, ямлы и вот это всё. Поэтому канал, скажем так, перекочевал в это русло. Теперь я за основу беру тот или иной инструмент, и в рамках этого инструмента стараюсь рассмотреть все его аспекты: от общей работы с ним до каких-то специфических штук. Но по привычке всё это делаю на OpenSUSE.

Что касается тематики думаю ясно. Теперь по поводу контента как такого. Почти все свои статьи я пишу сам. Понятно, что иногда я беру материал с того же Хабра или Медиума, обращаюсь к книгам и документации, но стараюсь делать это не в виде копипасты, а с добавлением каких-то интересных сценариев или реального опыта применения. Есть и такие, которые с нуля были написаны "от руки". Бывает и полная копирка, но тогда я обычно указываю в конце или начале статьи, что это вольный перевод. Так или иначе, данное место больше стоит рассматривать как блог или сборник статей по тем или иным темам. Эдакий awesome-devops в формате статей в телеграфе. Я не слежу за новостями и не собираюсь их публиковать. Не публикую и какие-то ссылки на другие статьи с посылом, мол вот что-то есть, пойдите да посмотрите. Это не мой формат. От того посты появляются не так часто, как хотелось бы. Я бы сказал в среднем на написание уходит неделя. Поэтому если кого-то такие перерывы напрягают, то увы. Есть еще пару идей, как разнообразить канал, чтобы не выглядел так уныло с постами раз / два в месяц, но это чуть позже. А так всем желающим и присутствующим рад. Планирую рассмотреть ещё много других технологий, так что скучно быть не должно. К слову, в ближайшее время опубликую новую статью по Vault.

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