HSLdevcom / digitransit-mesos-deploy

*NOT IN USE ANYMORE* Mesos deployment for Digitransit platform
2 stars 3 forks source link

Variables in group_vars/all/encrypted.yml #94

Open herrbpl opened 5 years ago

herrbpl commented 5 years ago

Hi.

We are trying to set up digitransit infrastructure in Azure.

It seems, that lot of variables are encrypted in https://github.com/HSLdevcom/digitransit-mesos-deploy/blob/master/group_vars/all/encrypted.yml with unknown Ansible Vault password.

So it is now little bit unclear if there should be more explanation regarding this file and environment setup. Do I need to create my own version of this file with my own variables? But if so, which are expected to be present in file?

Could HSLdevcom please provide unencrypted example of this file?

Thanks,

Siim

optionsome commented 5 years ago

Sorry the documentation for this repository is not quite up-to-date. It is expected that there is a file named vault_password in the root of the project which contains the password to decrypt ansible-vault file in group_vars/all/. That file should contain rows with key: "value", and these keys and values are used to replace certain strings from digitransit-azure-deploy/files/. You can find how the decrypt/encrypt logic works in https://github.com/HSLdevcom/digitransit-mesos-deploy/blob/master/digitransit-azure-deploy/tasks/main.yml. Those tasks are either run when decrypt, encrypt or deploy tag is given. Some of those tasks loop over list of files and those lists can be found in https://github.com/HSLdevcom/digitransit-mesos-deploy/blob/master/digitransit-azure-deploy/defaults/main.yml. You can find examples on how to run those scripts in https://github.com/HSLdevcom/digitransit-mesos-deploy/blob/master/examples.

What is required to be present in the encrypted.yml kinda depends on what services you are deploying and even if you deploy some service that could use sentry for example, it is not necessary for it to work so you can just remove the sentry related env variables from the files if you want. Docker credentials are necessary for data builders (wrongly named as -data-container in hsldevcom).

example encrypted.yml file

# password for fontstack, HSL specific thing
fontstack_password: "<password>"
# sentry is not really mandatory but we use it for logging errors
# sentry dsn secrets are in this format
dev_sentry_dsn: "https://<user token>@<address>/<project>"
prod_sentry_dsn: "https://<user token>@<address>/<project>"
# and some of them are in this format
sentry_secret_dsn: "https://<user token>:<password token>@<address>/<project>"
sentry_routing_secret_dsn: "https://<user token>:<password token>@<address>/<project>"
# these are credentials for used by digitransit-sentry-analytics but that repository is not really important
sentry_token: "<api token>"
# basic auth for digitransit-sentry-analytics
sentry_user: "<username>"
sentry_password: "<password>"
# docker credentials for pushing images
docker_user: "<username>"
docker_auth: "<password>"
# slack webhook url, not really mandatory but we use it monitoring
slack_webhook: "<slack_webhook_url>"
# digitransit-deployer checks/reports differences between this repo and what is actually deployed in environments and it needs the vault password for it
ansible_secret: "<what is stored in vault_password>"
# maanmittauslaitos API key for pelias-data-container (it is actually a data builder that creates a data container)
mmlapikey: "<api key>"
# the following are base64 encoded basic auth credentials for some APIs
old_lissu_basic_key: "<credentials>"
new_lissu_basic_key: "<credentials>"
jojo_basic_key: "<credentials>"
linkki_basic_key: "<credentials>"
vilkku_basic_key: "<credentials>"
lappeenranta_basic_key: "<credentials>"
# HSL specific timetable API
taku_api: "<url>"
taku_key: "<api key>"

Our configuration files are meant for running on DC/OS marathon stack with version 1.8 DC/OS and version 1.3.6 marathon. If you now deploy ACS in azure, you will get a newer version and you need to change some parts of the configuration. Also an important note, ACS will be deprecated from Azure at the beginning of 2020 and so I don't encourage deploying ACS for production use right now. We will soon start moving our environments somewhere else and most likely we will end up writing configuration for some other Docker orchestrator.