«Все как код» - это философия, которая рекомендует, чтобы мы все проверили в git, чтобы в случае бедствия (скажем, пандемия c, уничтожающего вашу рабочую силу ...), вы могли однажды восстановите все из вашего git репозитория и некоторых бинарных репозиториев, в которых хранятся используемые вами библиотеки. Под «всем» я имею в виду исходный код, систему сборки, все конвейеры и всю инфраструктуру.
Недостаточно поддерживать ваш исходный код в репо git, потому что, если он не ясен как это должно быть построено, тогда это имеет мало значения. Например, система 250klo c (тысяча строк кода) java может выглядеть так, как будто она будет компилироваться с java -8, но может быть некоторая логика c, которая работает только под java - 6. Вы предполагаете, что это java -8, потому что 250klo c - это слишком много кода, чтобы его можно было прочитать и понять, поэтому вы создаете и запускаете его, и он взрывается в работе, потому что вы использовали неправильный компилятор или другой дистрибутив Linux. Если вся ваша среда сборки также находится в коде и может быть легко воспроизведена, то этого не произойдет. Вы можете просто запустить docker image build --tag mycompany/myimage . (или, что еще лучше, использовать Makefile и просто запустить make), и все ваше приложение будет перестраиваться с использованием инструментов, предназначенных для первоначальных разработчиков.
Конечно, мы не Для того чтобы это было полезным, нужно прибегнуть к пандемии c. Попытка создать проекты с открытым исходным кодом без подробных инструкций - это PitA (Pain in the Ass), и даже с инструкциями может потребоваться вечность, чтобы найти нужные библиотеки и инструменты, загрузить их все и заставить их работать вместе. Эта проблема усугубляется, если вы не очень хорошо знаете набор инструментов (или вообще). Поместите инструкции по сборке в контейнер docker и boom - у вас есть сборочный проект, который почти тривиально построить с помощью тестируемого и исполняемого набора инструкций.
Этот шаблон настолько мощен, что в наши дни я собираю все в docker и включите Makefile, чтобы гарантировать, что даже команда docker выполняется так, как я планировал. Гораздо проще набрать make build, чем соответствующие команды docker. И все это посвящено git вместе с исходным кодом для моих проектов.
Причина, по которой мы используем многоэтапные сборки, заключается в том, что это проще, чем иметь несколько docker файлов, хотя в основном это одно и то же вещь, но с меньшими накладными расходами и меньшей вероятностью ошибок. Существуют многоэтапные сборки, так что вы можете включать компиляторы и аналогичные инструменты на этапе сборки и отбрасывать их в окончательном образе.
Одним из многих преимуществ этого подхода является то, что нам нужно только указать нашу процедуру сборки один раз, и он будет работать где угодно. При интеграции с инструментами непрерывной интеграции (CI) это избавляет нас от необходимости узнавать, как построить наше приложение с этим конкретным c инструментом, и избавляет нас от ошибок, возникающих, когда мы строим вещи в CI не так, как разработчики. Если вы используете контейнерную сборку, вам будет гарантировано, что разработчики и платформа CI одинаково работают одинаково, используя одни и те же инструменты, что помогает избежать ошибок класса «работает на моей машине». Это также ускоряет разработку ваших конвейеров, потому что вам нужно только сконфигурировать конвейер для запуска сборки docker (или, как упоминалось ранее, 'make'). Этот метод обеспечивает «повторяемость» вашей сборки (или, скорее, он должен обеспечить это, если все сделано правильно - все равно довольно легко ошибиться).
Я настоятельно рекомендую перейти на этот подход. как можно скорее. Это обязательный подход во всех крупных корпорациях, в которых я недавно работал (в основном в крупных европейских банках). Как только вы привыкнете к этому, предыдущие подходы кажутся в лучшем случае узкими, а в худшем - просто неправильными. Такой подход сэкономит вам много времени и усилий и приведет к созданию систем более высокого качества, которые намного проще в обслуживании, особенно в эти трудные времена.