Newer
Older
The deployment runs as `root`, which has access to e.g. gitlab.
The formula is organized in projects.
```yaml
deploy:
projects:
project_name: {}
```
For each project an additional user with the name `project_name` gets created.
This user should be used to run daemons.
## states
This formula comes with seperate states that work on integrated pillar.
This allows us to compose them as need.
### `deploy.gitlab`
Deploy code from gitlab to the server.
### `deploy.venv`
Create a virtualenv for a project.
### `deploy.django`
Writes a `prod.py` settings file and allows running `migrate` and `collectstatic` for a django instance.
Roll out certificates that you need for the deployment.
## bundles
You need to combine states together based on what you want to deploy.
Bundles are state files that include the wanted states together.
They also include other formulas for you (but you still need to configure them by yourself using pillar).
### `deploy.bundle.python`
Grab code from gitlab and create a virtualenv.
### `deploy.bundle.django`
Grab code from gitlab and create a virtualenv and take care of django settings.
Optionally you can enforce `migrate` and `collectstatic`.
### `deploy.bundle.django-service`
This combines `deploy.bundle.django` and `systemd.unit`.
It requires the `systemd-formula` to be available.
### `deploy.bundle.django-uwsgi-nginx`
This combines `deploy.bundle.django`, `deploy.certs`, `nginx` and `uwsgi`.
It requires the `uwsgi-formula` and `nginx-formula` to be available.
## pillar
When you decided which states are necessary you need to confgure the states using pillar.
```yaml
deploy:
config: {}
projects: {}
certs: {}
```
### `deploy.config`
This part of the pillar provides overall configuration data for the deployments.
It usually should not differ between deployments and might be assigned to many minions.
**Deprecated** Use [gitlab deploy tokens](https://doc.it.hs-hannover.de/books/sysadmin/page/gitlab-deploy-with-token-and-without-ssh) instead:
Static files related settings that are magically set by the `deploy.django` state.
- `deploy.config.static_url` _default: `https://static.it.hs-hannover.de`_
Static files related settings that are magically set by the `deploy.django` state.
### `deploy.projects`
This is the heart of this formula.
Here you describe your deployment(s).
```yaml
deploy:
projects:
project_name:
gitlab: {}
venv: {}
django: {}
cert: {}
```
Projects are a name and the configuration for the corresponsing states.
The name is used for several things within the deployment.
**NOTE** that you need to assign the states properly.
Only describing e.g. `cert` for a project without applying the corresponding state `deploy.certs` does not roll our your cert.
The branch, tag or commit that should be deployed
The `path` to the target directory is created by using `deploy.config.deploy_directory` + `/` + `project_name`.
#### `deploy.projects.[...].venv`
You may specify `venv: True`, which leads in default values.
Instead of True `venv` can also be an object.
The URL to clone from.
The python version is fixed to the servers python3 version.
The environment creation runs in the context of the project user.
#### `deploy.projects.[...].django`
- `settings_path` _default: `project_path/project_name/settings/prod.py`_
Specify django settings in yaml - they are written into a file in the project.
This fits our django settings approach.
#### `deploy.projects.[...].user_groups`
Each project receives a user that should be used to run the project (if it is runnable somehow...).
By default this user is member of the groups: `[project_name]` and `virtualenv`.
With `user_groups` you can define additional groups the user should belojng to.
This is especially interesting for access to cert data.
If your run user needs to read a cert, you might add him into the corresponding group.
### `deploy.certs`
Each cert may have the following fields:
The certificate chain - usually without the root certificate.
The root certificate - this is usually not necessary, except you roll out your own PKI.
The diffie hellman parameter.
The states will create a bunch of files in the `deploy.config.cert_directory`.
- `certname.pem`
- `certname.key`
- `certname.chain.pem`
- `certname.cacert.pem`
- `certname.dhparam.pem`
- `certname.fullchain.pem`
There is group created for each certificate based on the name and prefixed with `cert-`.
If your cert is called `helloworld` this leads to a group called `cert-helloworld`.
Put users that should read them into those groups.