Build the docker image
docker-compose build
cp docker-compose.override.yml.example docker-compose.override.yml
and set it up.
You should need to do this only once...
-
Check that your VPN is working and you can access the reference server.
-
Set the correct SSH hostname in inventory/production.yml.
-
Set the correct credentials and information regarding the GitHub Deployments in .env
cp .env.template .env vi .env
-
Run the container (this opens a shell):
docker-compose run --rm -u $(whoami) ansible-obs
-
Check the diff of the changes you are going to introduce
bin/obs_deploy check-diff
-
Check if there is a monkey patch in the server and act accordingly
-
Deploy using the correct playbook, they are described below.
ansible-playbook -i inventory/production.yml $playbook
-
Or check out the other things you can do with
obs_deploy
andogd
bin/obs_deploy -h ... bin/ogd --help
Depending on what you deploy, we have some different playbooks...
Most of our deployments only contain code changes that don't introduce any changes on the database schema, data or require downtime for any other reasons.
ansible-playbook -i inventory/production.yml deploy_without_migration.yml
If we detect that there is any schema or data migration in the deployment, this will abort. If that is the case, check the other options below.
Many database/data migrations are non-disruptive and therefore don't cause downtimes. This playbook will not put the OBS into maintenance mode and apply the migrations online.
ansible-playbook -i inventory/production.yml deploy_with_migration_without_downtime.yml
In many cases, database migrations require to stop all interactions of the application with the database while they are getting executed. Therefore causing downtime.
ansible-playbook -i inventory/production.yml deploy_with_migration.yml