FEATURE: New structure for kit template files

[YevheniiVolosiuk]

What do you think about this structure and its advantages and disadvantages?

infrastructure └── apps └── project-name ├── bin ├── dev │ ├── php │ │ └── Dockerfile │ ├── nginx │ │ └── Dockerfile │ ├── supervisord │ ├── .env.dev │ └── docker-compose.dev.yml ├── prod │ ├── php │ │ └── Dockerfile │ ├── nginx │ │ └── Dockerfile │ ├── supervisord │ ├── .env.prod │ └── docker-compose.prod.yml ├── staging │ ├── php │ │ └── Dockerfile │ ├── nginx │ │ └── Dockerfile │ ├── supervisord │ ├── .env.staging │ └── docker-compose.staging.yml ├── deploy_settings.yml ├── docker-compose.yml └── README.md

[rcravens]

Thanks for the proposal. If I am understanding correctly, you propose having in each app directory a "dev", "prod", and "stage" directory to contain the different environments. I had the same idea at one point. I wanted to support any number of environments. For a bit of time, I even had a "stage" env files in each template.

Recently, I stripped out the "stage" environment and simplified to two envs: "dev" where the code is mapped via a composer volume directive and "prod" where code is git cloned into the image. My thoughts are that I can then push that image anywhere (any number of servers) so that I could push that to the "prod servers" or to the "test servers" or the "stage servers".

I'm sure there is some complexity around the .env files that needs to be sorted out, but maybe those can be variables in the composer.prod.yml file?

I was going towards a place where the only difference between the "dev" and "prod" composer images is how code is incorporated into the image. Feels like it simplifies a lot....but I could be missing something.

[rcravens]

I see there is an issue with other environments needing there own .env file. Right now the "kit image" command builds an image using the ".env.prod" (at least in the laravel template). What if we added an optional argument like "kit image " where you could override which env file is used. So "kit laravel image stage" would look for a ".env.stage" file?

That seems to give you the freedom to build these additional environments while keeping the complexity lower? What do you think?

[rcravens]

[rcravens]

I updated the laravel template to have a "envs" directory. i'm going to update the other templates to use this same structure. i think this is a combination of two types of "docker builds" (one with code in volume, the other with code inside) and still allowing the possibility of having a "stage" environment when we run "kit image "

[rcravens]

i just completed this work for all the rest of the templates. I also did the following:

• created a 'kit make env ' command that copies the 'dev' environment into a new one
• updated 'kit image ', 'kit push ', and 'kit deploy ' to all accept and variable.

[YevheniiVolosiuk]

From my perspective structure is looking a bit confusing becouse we put all the files in one place. In the root, dir better to have just a default base or global files.

Also when we start adding the php dev settings and nginx etc. they will in just 1 dockerfile as I understand and this file will be grow all the time. I am also thinking about docker-compose.ci.yml, docker-compose.testing.yml, and files with configs for them too.

Also for the command line maybe was better to have it?

kit new laravel <app> option --environment=all or prod or ci or testing

kit new laravel will ship with just the dev/ folder

kit <app> prod create kit <app> steg create kit <app> ci create kit <app> testing create

after one of these commands, it will add folder dev/ or prod/ or stage/ etc to the app that we will specify, and in this way will be simpler to create files and make sh scripts for them and navigate to folders if we want to change something, you go to steg or dev folder and you now all files just contain to this env.

Also about databases a few simple commands for export and import quickly from specific folders and they must be separated too for dev, prod, etc.

kit db dev install ## installs into container database the init sql file from resources/database sudo docker exec -i $(DOCKER_CONTAINER_NAME_PREFIX)-db sh -c 'exec mysql $(DOCKER_DB_DATABASE) -uroot -p"$(DOCKER_DB_PASSWORD)"' < docker/infrastructure/dev/mysql/dev-mysql-init.sql echo ${C_YEL}"DATABASE"${C_END}" has been installed."

kit db dev replace ## replaces container database with the latest sql backup file from resources/database sudo docker exec -i $(DOCKER_CONTAINER_NAME_PREFIX)-db sh -c 'exec mysql $(DOCKER_DB_DATABASE) -uroot -p"$(DOCKER_DB_PASSWORD)"' < docker/infrastructure/dev/mysql/dev-mysql-backup-$(CURRENT_DATE).sql echo ${C_YEL}"DATABASE"${C_END}" has been replaced."

kit db dev backup ## creates / replace a sql backup file from container database in resources/database sudo docker exec $(DOCKER_CONTAINER_NAME_PREFIX)-db sh -c 'exec mysqldump $(DOCKER_DB_DATABASE) -uroot -p"$(DOCKER_DB_PASSWORD)"' > docker/infrastructure/dev/mysql/dev-mysql-backup-$(CURRENT_DATE).sql echo ${C_YEL}"DATABASE"${C_END}" backup has been created."

It's code from my make file, and I added this for a better understanding.

In the end, it was good to have a few commands to shell in docker containers. About the problem with env files, I have not caught your point to the end if we have a separate folder in each environment will be just one env file and we can simply call these files with --env-files in docker commands. Also, I found this repo https://serversideup.net/open-source/spin/ it's very similar to what you are building, and Idia with templates was good becouse they don't have many prepared too.

Sorry for a lot of ideas, I just trying to show my perspective, maybe something will be nice to have ;)

[rcravens]

thanks for the feedback. i will take a look and think about it some more. the next couple of days, i want to try and prototype the ansible code to provision a complete server environment. i will circle back to this after that.