Projects deployments and lifecycles

WIP doc


You need a sudo access on the remote machine, which can typically be obtained with the playlabs init command ie.:

playlabs init root@

# 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


playlabs @somehost deploy image=betagouv/mrs:master
playlabs @somehost deploy
playlabs @somehost deploy


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, 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
  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
  • tasks to execute after deploy of the project image
  • included in template before the backup
  • included in template before the backup
  • included in template before the restore
  • included in template before the restore

Default plugins live in playlabs/plugins and have the following files:

  • take files out of containers and add them to the $backup variable
  • clean up files you have taken out after the backup has been done
  • clear the place where you want to extract data from the restic backup repository
  • 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
  • ansible tasks to execute after project deployment, ie. create users from inventory
  • vars.yml plugin variables declaration


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:

  • standalone command to start the project container, feel free to have on that one
  • cause a secure backup, upload with lftp if inventory defines dsn
  • 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
  • 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, then it will fetch the repository with lftp.