Skip to content

linux

As-Code как ДНК актуальной инженерной культуры

Недавно на митапе о стандарте разработки нам с Heads of Profession задали вопрос, который завис в воздухе, как нерешенный баг в коде. Пятый по популярности в сообществе, он звучал так:

“А что за потребность всё делать %-as-code? Какая от этого польза? Зачем число комитящих в код?”

Мы, как архитекторы инженерной культуры, внедряем лучшие практики и подходы: Infrastructure-as-Code, API-First, unit-тесты, компонентное тестирование, TBD (trunk based development), GitOps, Doc As Cod, ..as code. Хаос необходимо упорядочить. Мы дорабатываем пайплайн, как инженеры, собирающие сеть в подвале старого дата-центра. Мы создаем условия для Continuous Deployment с продуктовыми платформами, где blue-green deployment и canary deployment становятся порталами для перехода прода из одного состояние в другое..

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

Я провалился в момент осознания вопроса в другой слой реальности, задумался об истории ..as code и собрал этот текст из разбросанных по сети слепков.

И когда кто-то спрашивает: “Зачем?”, я отвечаю: “Потому что иначе мы останемся в прошлом, где ручные процессы, как старые провода, тянут нас назад в тишину, замедляя каждый шаг. ” Мы строим мир, где as code не просто слова, код - наша новая реальность. И каждый, кто коммитит, становится частью этой вселенной.

Концепт "as code" зародился как реакция на вызовы современной ИТ-индустрии: сложность, скорость изменений и необходимость автоматизации.
As code концепт стал естественным продолжением эволюции разработки, где код стал не только инструментом создания программ, но и способом управления инфраструктурой, документацией, архитектурой и политиками. Этот подход продолжает развиваться, интегрируя новые технологии, такие как AI, и становится стандартом для современных ИТ-компаний

"as code" глубоко корнями тонет в 1970-е годах. Ранние инструменты, такие как Unix "make" и PXE boot, заложили фундамент для автоматизации конфигураций, которые позже эволюционировали в современные подходы, такие как Infrastructure-as-Code, Documentation-as-Code и GitOps. Это подчеркивает, что "as code" — это не просто тренд, а естественное развитие технологий, направленное на упрощение управления сложными системами.

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

Immitable Linux CoreOS как среда для бегущего в Gitlab тест контейнера

Привет, netrunner. Мегасити никогда не спит. Мегасити майнит все, что может переварить машина. Последний звонок по работе пыльным облаком упал тебе на плечо и отразилось болью в мышце спины.

Ты думаешь, что можешь справиться с этим? Ну-ну. Посмотрим, как ты справишься с миром, где неизменность — это не просто концепция, а жестокая минималистичная реальность.

Когда наступает ночь, ты обнаруживаешь, что пишешь веб-бук про эффективное программирование. Ты собираешь свое домашнее облако, как будто это твой личный кибернетический рай, и экспериментируешь с железяками, linux дистрибутивами и devOps инструментами. Надежный удобочитаемый код — это твоя мания, твоя одержимость.

Ты готовишь Gitlab Runner для запуска тест контейнеров на отдельной машине и решаешь взглянуть на неизменность (Immutable) в срезе программирования и администрирования. Immutable Linux и immutable классы в объектно-ориентированном программировании — это твои новые игрушки, твои инструменты для пыток.

Тебе не хочется писать ansible скрипты, нет. Ты хочешь исследовать неизменяемые дистрибутивы Fedora CoreOs и openSUSE MicroOS. Один файл для конфигурации, и флешка для “прожига” машин — вот твоя цель. Простая документация? Она не имеет значения. Да кому она нужна! Файл в гите отныне твоя документация.

Ты хочешь понять, как быстро ты сможешь разобраться с примером. Уже полночь. Кофе остыл. Слышна тихая песня машины у тебя под боком. Тоже мне чертов электрокот.

Ты наслаждаешься экспериментом с Immutable Linux, гарантируешь автономную накатку инструментом самого дистрибутива и изготавливаешь gitlab runner для test containers. Всё получается быстро, слишком быстро. Пять часов — и всё работает. По пути ты пишешь о важных темах.

Ты пишешь эссенцию, чтобы не забыть и не свихнуться:

  • об Immutable Linux, особенно о Fedora CoreOS
  • о неизменяемых классах и преимуществах жизни в мире immutable null safety
  • пример конфигурационного файла CoreOS для рабочей машины типа Gitlab Runner

Ты думаешь, что получилось интересно? Надеюсь, ты прав.

Запуск Gitlab Runners на отдельной ВМ или хосте — это наилучшая практика. Ты знаешь это и готов к этому вызову.