Това описание преминава през част от мисловния процес, който ръководи нашия „шаблон за проект“, който беше обсъден на по-високо ниво в отделна публикация:
Технологичен агностик: По-голямата част от нашия проект използва различни технологии, като ruby, python, nodeJS или други. Така че шаблонът на нашия проект трябваше да бъде агностик към тези технологии. Това беше основната причина, поради която шаблонът използва главно shell, docker и docker-compose. С контейнерите вече нямахме нужда от инструменти за управление на версии като rvm, rbenv, chruby, pyenv, virtualenv, nvm и т.н., защото просто трябваше да променим версията в Dockerfile.
Shell скриптове: Терминалът е общата зависимост на всички наши услуги. Следователно ние написахме всички наши типични задачи на shell, а не на конкретен език, дори ако скриптът на обвивката просто извиква задача ruby или python. Нашите общи задачи включват:
- стартиране на проекта: Тази задача помага на новите разработчици да стартират проекта. Освен това той гарантира, че проектът е „чист от артефакти“ от предишна задача/функция, така че при стартиране на нова задача/функция проектът/контейнерът е в очакваното състояние.
- настройване на приложението: Тази задача включва неща като създаване и мигриране на базата данни. Той може също така да зареди базата данни, така че разработването на функции на потребителския интерфейс ще бъде по-лесно, тъй като има съществуващи данни за тестване.
- стартиране на приложението: Тази задача стартира сървъра. Подробности като указване на портове и премахване на PID на предишни сървърни процеси също могат да бъдат полезни в този скрипт.
- тестване на приложението: Тази задача изпълнява тестовете и може също така да изпълнява линтери, проверки на стил/формат и други статични анализатори на код.
- архивиране на приложението: Тази задача архивира данните и схемите, необходими за приложението. Приложението може да използва множество бази данни, така че този скрипт ще се погрижи за тези видове неща.
За да споделим общи подзадачи между всеки от скриптовете, дефинирахме shell функции. Неща като изчакване сървърът на базата данни да работи ще се поберат в този файл.
Друго предимство от това, че тези често срещани задачи са скриптирани, е, че те могат да се обработват доста лесно от CI/CD конвейер.
Контейнери за многократна употреба: Нашият подход е да използваме настройките по подразбиране колкото е възможно повече, за да останем в съответствие с предположенията, направени от създателите на инструментите. Така например нашите основни Dockerfile и docker-compose.yml файлове се намират в основата на проекта. Това улеснява използването на команди като docuer-compose up.
Въпреки това, за да можем да използваме повторно контейнерите, когато друг зависим проект изисква текущия проект, ние extend docker-compose.common.yml, който съдържа общите конфигурации, които са необходими за инстанциране на услугата. Това позволява на зависимите проекти да включват текущия проект като git submodule и extend от същия docker-compose.common.yml.
Друго предимство от използването на контейнери със скриптове на обвивката е, че приложението се зарежда и се настройва по един и същи начин всеки път, като по този начин се избягва проблемът „работи на моята машина“. Зависимостите на операционната система са посочени в Dockerfile. Променливите на средата са посочени в development.env, които са всмукани в контейнерите чрез docker-compose).
И това е. Това е ядрото на шаблона на проекта, който използваме. Помага ни да вземем и да бъдем продуктивни бързо при всяко от нашите приложения, както и да избегне изхвърлянето на велосипеда. Надявам се да е полезен и за вас и ако знаете начини за подобряване на шаблона, моля, уведомете ме.
