Когда проснулся и понял, что просто нужно начать эту жизнь жить и строить пайплайны 🌅

Под самый конец прошлого года чутка хайпила статья в узких кругах по поводу Claude Code. Немного запоздало, но я хочу опубликовать её у себя в переводе с вольной интепретацией. И хотя не то чтобы многое изменилось с конца декабря 2025 года (когда был опубликован оригинал). С другой стороны, в публикации всё крутится вокруг таких моделей как Opus и Sonnet 4.5, но в случае с Opus уже вышла версия 4.6, а для Sonnet версия 4.6 на подходе. В статье, в основном, убрал почти всю лулз часть про твиттер и мемы, так как меня это мало интересует и чуть расширил технический бэкграунд. Хотя на деле невозможно вместить весь пласт информации по затронутым темам.

В целом конкретно эта статья по стилю выбивается из тех, что я обычно публикую. К ней стоит относиться как к большому интро по Claude Code в разговорном формате, потому что помимо обычных статей я, постепенно, хочу расширить для себя тему консольных агентов. Так что это эдакий спойлер того, что мне, как минимум, хочется затронуть. Сам Claude Code давно использую, но всё это было в режиме пользования из коробки, без улучшайзинга так сказать, и только для DevOps-задач (об этом кстати меньше рассказывают, чем о программировании, так что тут есть где развернуться). Я не буду разводить здесь AI-полигон, если вдруг кого-то такое может оттолкнуть с учетом хайпа вокруг темы. Просто хочу сам чуть предметнее погрузиться в данную тему и может это будет интересно ещё кому-то. Ибо инструментов и обвязок становится всё больше, и уже обычное исполнение ~> claude в консоли вместе с промтом по делу пока ещё работает, но с каждым днём сильнее проигрывает тем, кто использует расширенные возможности Claude Code.

Классический вариант статей по каким-то штатным DevOps-штучкам никуда не денется. Как раз лью воду для новой публикации.

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

Продолжаем про инструментарий для сборки образов. В этот раз разберем основные возможности, которые предоставляет Buildah. Я не стал уже заморачиваться, так что всю статью посвятил непосредственно самому Buildah, по аналогии с BuildKit. В следующей части поговорим про уже форкнутый Kaniko в исполнении Chainguard.

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

Я ещё думал отдельно сделать обзор на Ko, Jib и прочие тулы, которые направлены на работу с конкретными языками программирования, но непонятно, насколько это интересно / востребовано. Пока что ДУМАЕМ.

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

Чисто для разнообразия накину. На днях было собеседование с HR. Началось всё со стандартных вопрос / ответ в обе стороны. Спустя 15 минут, когда прошли этап прелюдий, она внезапно вывалила:

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

Я уже напрягся, потому что понимал, что пахнет шизой, но думаю дай посмотрю, чего выйдет. Открываю гугл форму и вижу там следующий список вопросов:

1. Твой интеллект дан от природы, и его нельзя изменить?
2. Ты такой, какой есть, и этого не изменить?
3. Музыкальный талант может освоить любой?
4. Математика даётся легче мужчинам?
5. Чем больше над чем-то работаешь, тем лучше становишься?
6. Люблю, когда мне говорят о моих успехах и неудачах?

7. Способность учиться у всех одинаковая?
8. По-настоящему умные люди не должны сильно стараться

И варианты ответа Да / Нет. Я бы с радостью приложил картинку в рамках поста, да спасибо дяде Паше за лимиты. Оставлю в комментах. В общем случае испытал смешанные чувства. Тут даже уже не возникает вопроса уровня «а, собственно, для чего это нужно?». Все уже привыкли, что во время найма могут вкидывать любую хрень. У меня сразу в голове стукнуло по типу «а как вообще можно ответить однозначно да или нет на некоторые вопросы?». Особенно на всё, что касается интеллекта. Я не хочу душнить и умничать, но сам факт того, как мы пытаемся оценить, уже влияет на то, каким будет ответ. Мы с точки зрения нейробиологии оцениваем? Или учитываем социальный фактор? А может ещё что-то? Ну понятно, что это риторический разгон, однако сам факт остается комичным.

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

Она открывает ответы, смотрит, зависает на секунд 10 и такая:

Первый раз получаю такой результат. У вас 0 из 8 правильных ответов.

Я тут уже разогрелся. Спрашиваю её:

А что значит правильные? Есть какое-то четкое определение что правильно в данном контексте?

Она отвечает:

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

Понял. Кстати всегда знал, что мнение о талантах в музыке напрямую связано с тем, как ты будешь с типами в команде коммуницировать. Тут, как говорится, поверил + понял. Ну а дальше я поблагодарил за такую продуктивную беседу и сказал пака-пака.

Самое смешное, что это даже не крупняк какой-то с их вечными шизоэтапами ни о чем. Обычная контора с тасками уровня ООО "ИБАШ И БАШ".

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

Никто не ждал. Никто не просил. Но надо запостить.

Кто давно подписан тот знает, что среди старых постов можно найти цикл статей и по Vault. Я давно его не продлевал и этим обязательно займусь по мере возможного. Однако вместе с написанием статей по той или иной теме в контексте Vault я также занимался компиляцией различных вариантов того, как сам Vault и всё сопутствующее для него развернуть в два клика. В какой-то мере это делалось для будущих статей в рамках всё того же цикла, которые в голове держу (сами статьи), но на практике не были опубликованы. С другой стороны, какая-то доля самообучения здесь тоже присутствует.

По итогу вышел данный репозиторий. Он построен вокруг таких инструментов как Ansible (для развертывания Vault как сервиса) и Terraform (для его конфигурирования). Хотя на деле там есть и много всякой вспомогательной шляпы. Более того, я туда не добавил всё что хотел, как, например, часть про Kubernetes. В корне лежит просто огроменное ридми, которое ответит и на все вопросы по типу как использовать, что представляет собой, какие варианты и т.д., и т.п. Пожалуй, разве что в нём нет главного вопроса: а нафига это всё надо? В общем-то явной цели или причины не было. Ради кекесов и лулзиков, как говорится. Сейчас, в эпоху консольных агентов, и подавно этот набор конфигов может не понадобится, потому что всё за тебя сделают, но надо же кому-то показать свою полезность с гитхаба, иначе жизнь не жил считай.

Короче я бы относился к проекту больше как к образовательному месту или эдакой большой статье в парадигме проекта на Github, где показано как можно конфигурировать Vault в зависимости от того или иного сценария (больше в административном контексте). Я бы сказал, что реализовал где-то 50% от того, что хотел или как это видел, так что через годик надо будет v2 сделать 🙃 Ну и жопу ставлю что ансибло/терраводы панамок за шиворот могут напихать. Я это рефакторил раз 5 и всё равно уверен, что найдутся ошибки. Но роли точно рабочие, не зря же Molecule была звезена туда 😎

Лично я кайфую только с одного: с роли по автоматическому распечатыванию для Standalone/Cluster варианта. Там действительно предусмотрено большинство вариантов – инициализация, распечатывание, повторное распечатывание, наличие/отсуствие Auto-Unseal и т.д. Помоему только не предусмотрел вариант, когда формально ты вообще с улицы пришел со своими ключами к Vault, который ранее никак через репозиторий не ставил и хочешь чего-то распечатать. Хотя с точки зрения design уже всё готово чтобы добавить такую опцию.

Абсолютно проклято.

Более того, комментарии там только бафают веру в этот сгусток вселенского зла.

TL DR:

Чел в резюме записал рецепт пельменей и прошёл ИИ-фильтры. HR только на собесе понял и там же в целом удосужился посмотреть, а что же было написано в этом самом резюме.

Ладно, пофлудили и хватит. Про образы ещё не всё разобрали. На самом деле эта статья несколько сумбурной вышла с точки зрения прочтения, но мне очень хотелось затронуть различные механизмы и аспекты, участвующие в сборке, которые порой остаются неразобранными на достаточном уровне. С другой стороны, сил и времени на полное погружение для каждого из них тупо нет, поэтому постарался засунуть всё это в обертку «а что там происходит после docker build».

Итак, раз уж я заговорил о Claude Code, то теперь было бы неплохо что-то реально полезное опубликовать. Поэтому собрал для вас актуальную подборку всякого в перемешку по тематике данного консольного агента (а другие я и не признаю). Многие из этих ссылок, так или иначе, уже фигурировали на просторах тех или иных телеграм каналов, но вот очень хочется у себя тоже всё это собрать в одном посте. Пройдемся по пунктам:

1. Внезапно, а может и нет, официальная документация от Anthropic по Claude Code. Она действительно хороша. И там даже есть поддержка русского языка. После такого даже последний бастион отмазок должен был пасть.

2. Всем известный Roadmap.sh. Они не так давно выкатили дорожную карту в том числе и по Claude Code. Поэтому если вы хотите изучить Claude Code вдоль и поперек, то как путеводитель самое то. Более того, там же вышла ещё одна дорожная карта, но уже по Vibe Coding. Думаю, что тоже будет полезно.

3. Awesome по Claude Code. Представляет собой неофициальный сборник различных ресурсов и репозиториев, а так же каналов для получения информации по Claude Code. Просто огромное число информации по теме консольного агента. Этот же ресурс в лице Github-репозитория.

4. Каталог с множеством Skills. Представляет собой агрегатор, в котором на данный момент уже более 500 000 скиллов по самым разным тематикам и для самых разных агентов. В том числе есть большая выборка и для Claude Code.

5. Каталог всего для консольных агентов. Ещё один полезный ресурс в том числе для Claude Code, который содержит в себе множество скиллов, MCP, хуков, команд и т.д. Как минимум стоит ознакомиться.

6. Каталог промтов для кастомных субагентов. Содержит в себе 200+ промтов для Claude Code на самые разные темы в конексте разработки и построения инфраструктуры. Есть также список MCP для различных задач.

7. Github-репозиторий с набором полезностей раз. Сборка всякого для Claude Code с общим именем в лице Toolkit. От команд до MCP.

8. Github-репозиторий с набором полезностей два. Свежий и тоже содержит набор всякого для Claude Code. Можно присмотреться.

9. Github-репозиторий с набором системных промтов. Больше теоретический смысл имеет. Полезно, если хочешь разобраться во внутрянке работы агента.

Кидайте своё в комменты, если есть что-то такое, чем хотели бы поделиться (полюбому есть).

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

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

ДА ДА МЫ, НА ВАЙБИКЕ 😊(🥲)

Йоу. Я (не я) тут напедалил такой сайтик по командам для Kubernetes с помощью Claude Code. Так что больше нейрослопа Богу нейрослопов.

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

Помимо этого мне также было интересно как Claude Code справится со всем этим в руках человека, который от фронтенд мира держит максимальную дистанцию. В общем случае он написал весь каркас с одного промта просто заценив скриншот сайта. И всё это было на Sonnet 4.6, даже не Opus, хотя последнего я потом попросил оценить со стороны, что по итогу вышло. Дальше просто дрючил цвета и расположение, но это чисто мои перфекционистические загоны. Иронично, что Claude Design релузинули спустя пару дней как всё доделал.

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