Projects deployments and lifecycles¶
WIP doc
Pre-requisite¶
You need a sudo access on the remote machine, which can typically be obtained
with the playlabs init
command ie.:
playlabs init root@1.2.3.4
# all options are ansible options are proxied, so this also works
playlabs init @somehost --ask-become-pass
The ssh, docker and firewall playlabs roles must be installed on the server:
playlabs install ssh,docker,firewall,nginx @somehost
Deploying a docker image¶
Examples:
playlabs @somehost deploy image=betagouv/mrs:master
playlabs @somehost deploy
image=betagouv/mrs:master
plugins=postgres,django,uwsgi
backup_password=foo
prefix=ybs
instance=hack
env.SECRET_KEY=itsnotasecret
playlabs @somehost deploy
prefix=testenv
instance=$CI_BRANCH
image=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
Deployments¶
The project role is made to be generic and cover infrastructure needs to develop a project, from development to production. Spawn an environment, here with an example image this repo is tested against:
playlabs @yourhost deploy betagouv/mrs:master '{"env":{"SECRET_KEY" :"itsnotasecret"}}'
It will use the IP address by default if ansible finds it, set the dns with the
dns option dns=yourdns.com
, or set it in project_staging_dns
yaml
variable of your-inventory/group_vars/all/project.yml.
This is because the default prefix is project
and the default instance is
staging
. Let’s learn a new way of specifiying variables, add to your
variables:
yourproject_production_image: yourimage:production
yourproject_production_env:
SECRET_KEY: itsnotsecret
# the above value could be encrypted with ansible-vault s_encrypt
Then you can deploy as such:
playlabs @yourhost deploy prefix=yourproject instance=production
If you configure yourhost in your inventory, in group “yourproject-production”, then you don’t have to specify the host anymore:
playlabs @yourhost project prefix=$CI_PROJECT instance=$CI_BRANCH
Project plugins¶
PostgreSQL or Django or uWSGI support are provided through project plugins, which you may activate as such:
- specify
-p postgres,uwsgi,django
- configure
yourprefix_yourinstance_plugins=[postgres, uwsgi, django]
- add to Dockerfile
ENV PLAYLABS_PLUGINS postgres,uwsgi,django
The order of plugins matters, having postgres first ensures postgres is started before the project image.
Plugins are directories located at the root of playlabs repo, but at some point we can imagine loading them from the image itself.
Plugins contain the following:
- vars.yml: variables that are auto-loaded
- deploy.pre.yml: tasks to execute before deploy of the project image
- deploy.post.yml: tasks to execute after deploy of the project image
- backup.pre.sh: included in backup.sh template before the backup
- backup.post.sh: included in backup.sh template before the backup
- restore.pre.sh: included in restore.sh template before the restore
- restore.post.sh: included in restore.sh template before the restore
Default plugins live in playlabs/plugins and have the following files:
- backup.pre.sh take files out of containers and add them to the $backup variable
- backup.post.sh clean up files you have taken out after the backup has been done
- restore.pre.sh clear the place where you want to extract data from the restic backup repository
- restore.post.sh load new data and clean after the project was restarted in the snapshot version,
- deploy.pre.yml ansible tasks to execute before project deployment, ie. spawn postgres
- deploy.post.yml ansible tasks to execute after project deployment, ie. create users from inventory
- vars.yml plugin variables declaration
Operations¶
By default, it happens in /home/yourprefix-yourinstance. Contents depend on the activated plugins.
In the /home/ directory of the role or project there are scripts:
- docker-run.sh standalone command to start the project container, feel free to have on that one
- backup.sh cause a secure backup, upload with lftp if inventory defines dsn
- restore.sh recovers the secure backup repository with lftp if inventory desfines dsn. Without argument` list snapshots. With a snapshot argument` proceed to a restore of that snapshot including project image version and plugin data
- prune.sh removes un-needed old backup snapshots
- log logs that playlabs rotates for you, just fill in log files, it will do a copy truncate though, but works until you need prometheus or something
For backups to enable, you need to set backup_password, either with -e, either through yourpefix_yourinstance_backup_password.
The restic repository is encrypted, if you set the lftp_dsn or yourprefix_yourinstance_lftp_dsn then it will use lftp to mirror them. If you trash the local restic repository, and run restore.sh, then it will fetch the repository with lftp.