Dockerization Strategies

VERY project MUST be dockerized – native setups should be as minimalistic as possible – possibly requiring ONLY the following binaries – bash , zip , unzip, perl , jq , sed

• do-setup-<<component(s)>> – should build all the docker images , kick up the containers
• do-build- <<component(s)>> – should be able to compile, build , lint etc the code in the containers
• do-test-<<component(s)>> – should be able to test the code in the containers

All of the Dockerfiles should be callable via docker-compose file.

Pay attention to the dir structure and the FOUNDATIONAL variables:

• BASE_PATH
• ORG_PATH
• <<APPLICATION_PATH>>
• <<APP_COMPONENT>>_PROJ_PATH
• <<APP_COMPONENT>>_PROJ_PATH/src/<<runtime>>/<<MODULE>>

Use .env file for the current environment, Each environment must have a different .env file – GLOBAL variable names – aka PORT is bad, API_PORT better , <<COMPONENT>>_API_PORT best ..

Also make files do use the .env files.

EVERY project MUST be build with a single oneliner – make install , regardless of the amount of dockers ( aka docker components ) it is having. Whenever applicable add a single docker-compose based wrapper

EVERY docker component when running locally MUST map the volume of the <<APPLICATION_PATH>> directory in edit mode – aka changes MUST be doable life when the container is running

EVERY run-time running while the container is running MUST support “hot-reload” feature – aka changes to the source code MUST be directly reflecting without having to rebuild etc.

EVERY Dockerfile MUST be written to be as modular as possible :

• use START ::: install <<what>> , STOP ::: install <<what>>
• segregate logically the bins and packages on the OS package installer per row ( it helps building new Dockerfiles )