Infrastructure to support the iAtlas project
These resources are created by sceptre:
-
config/commonincludes the vpc and network attachments for the project. Also launches the GitLab runner instance. -
config/staginglaunches an aurora postgresql resource, kms key, and the api app for the staging environment. -
config/prodlaunches an aurora postgresql resource, kms key, and the api app for the production environment.
-
Update deprecated
docker-machineto usedocker-autoscaler.See:
-
Update deprecated Gitlab registration token to the new runner registration workflow.
See:
The config.yaml picks up a number of environment variables. All have defaults to ensure the build runs with meaningful error messages. Some of the environment variables MUSt be set.
-
GITLAB_CONTAINER_PASSThis is the password (token) for accessing the GitLab container registry. These are generated and found in GitLab (the main CRI-iAtlas project) under
Settings->Repository->Deploy Tokens. The scope should be "read_registry". See https://gitlab.com/groups/cri-iatlas/-/settings/repository#js-deploy-tokens -
GITLAB_CONTAINER_USERThis is the username for accessing the GitLab container registry. These are generated and found in GitLab (the main CRI-iAtlas project) under
Settings->Repository->Deploy Tokens. The scope should be "read_registry". See https://gitlab.com/groups/cri-iatlas/-/settings/repository#js-deploy-tokens -
GITLAB_REG_TOKENThis is the token for registering the Runner with GitLab. This is found in GitLab (the main CRI-iAtlas project) under
CI/CD->Runners->Register a group runner. See https://gitlab.com/groups/cri-iatlas/-/runners
The following MUST be created initially:
-
staging/iatlas-runner.yamlThe
stagingGitLab runner is used for general and staging environment builds in GitLab. Creating it will also create:common/iatlasvpc.yamlcommon/maintenance.yamlstaging/iatlas-kms.yamlstaging/iatlas-api-db.yamlstaging/iatlas-runner-s3-bucket.yamlstaging/iatlas-runner-roles.yaml
The database instance is needed so that the host values may be passed to the GitLab Runner. The host is a subnet and not available outside the VPC.
The KMS stack is needed for the Database.
The VPC is needed for the Runner and the Database.
-
prod/iatlas-runner.yamlThe
prodGitLab runner is used for prod environment builds only. Creating it will also create:-
common/iatlasvpc.yaml -
common/maintenance.yaml(these should already be created by the staging stack above)
-
prod/iatlas-kms.yaml -
prod/iatlas-api-db.yaml -
prod/iatlas-runner-s3-bucket.yaml -
prod/iatlas-runner-roles.yaml
The database instance is needed so that the host values may be passed to the GitLab Runner. The host is a subnet and not available outside the VPC.
The KMS stack is needed for the Database.
The VPC is needed for the Runner and the Database.
-
-
staging/iatlas-api-hostedzone.yaml -
prod/iatlas-api-hostedzone.yamlOnce the HostedZones are created for Staging and Production, NS records may be created in the domain registrar with values from the respective HostedZones.
ie - If the domain staging.example.com is to be used for the Staging API, create an NS record for the
stagingsubdomain in the domain registrar for each of the nameservers created in the HostedZone for that domain - route53.
- Install pre-commit app
- Clone this repo
- Run
pre-commit installto install the git hook
Create credentials file in your local user folder. The file should be called credentials located in ~/.aws.
The contents should look like:
[iAtlas]
aws_access_key_id = {ACCESS_KEY}
aws_secret_access_key = {SECRET_ACCESS_KEY}
aws_session_token = {SESSION_TOKEN}
region = us-east-1
Create config file in your local user folder. The file should be called config located in ~/.aws.
The contents should look like:
[default]
region = us-east-1
Install Python
See https://packaging.python.org/guides/installing-using-pip-and-virtual-environments/ for information on installing Python packages for a specific project.