Conversation
rebkwok
force-pushed
the
emistest-backend
branch
5 times, most recently
from
ea48844 to
63b743f
Compare
Airlock needs it to be set to _something_ in order to start up.
Add a pyproject.toml and minimal dependencies
Mimics test backend env, plus: Adds BACKENDS: The agent typically uses the default BACKENDS to verify that its BACKEND is valid; emistest isn't one of the default values yet, so we add an explicit BACKENDS var for this backend which will let the agent service start. Set TEST=true which will mean Airlock skips trying to update certicates when just autodeploy runs. Add a django allowed host that will let us connect to airlock from outside.
This adds a packer configuration file at backends/emistest/packer/emis-base.pkr.hcl which defines the steps required to build both an EC2 AMI and a vagrant test box. It defines 2 sources, emis-base, which uses the amazon-ebs builder, and contains the information needed to build an AMI, and emis-test, which uses the vagrant builder. Builds should be run through the just packer-build-aws/vagrant recipes, which specify an -only parameter and will build the specified source only. As much as possible, the 2 sources do the same things, so we can use the vagrant source to test the provisioning. It also runs using the same just commands and scripts as all the other backends as much as possible. The first step in the provisioning clones this repo using the specified branch, so that commands can be run from within the /srv/backend-server dir, as for any other backend. It has 2 additional custom scripts: 1) backends/emistest/scripts/install_aws_cli.sh, for the awscli installation, which is specific to emis. 2) clean-image.sh does some cleanup that's copied from backends/tpp/clean-image.sh Note that cloud-init files are not copied over for the aws source, they'll be used at instance launch. We also define different cloud-init config for vagrant and aws. In the aws cloud-init user-date, as an example, we fetch some test (secureString) secrets from aws parameter store and use it to populate a value in an env file. This will get run when we launch an ec2 instance from this AMI.
The cracklib-runtime package is needed for the forced password change on initial login. It seems to already be there in other backends (or maybe it's manually installed). In any case, it's not installed after the packer builder finishes, so include it in the list. Also check for the existence of motd scripts before chmod'ing them.
rebkwok
force-pushed
the
emistest-backend
branch
from
13332eb to
7613ab1
Compare
| # This file is safe to edit by hand: it will not be overwritten by config management | ||
|
|
||
| # Credentials for logging into the job server for this backend | ||
| JOB_SERVER_TOKEN= |
There was a problem hiding this comment.
I think hardcoding a dummy value this is fine for our own bearer tokens, as they are simple bearer tokens that must exactly matche, and a dummy value like this making it into production would be broken, but not insecure.
I wouldn't want to use it for django secret key type secret though, where a lack of randomness or known value in production would be a problem.
We could generate some randomness when we first copy the template, perhaps.
There was a problem hiding this comment.
I mean, I agree, but we do actually already do it for the django secret key, in this very file. I'm guessing it was for the same reason that I've added this dummy value, Airlock won't start successfully without it
| @@ -0,0 +1,34 @@ | |||
| #cloud-config | |||
| # having an explict user specified disables the default ubuntu user | |||
There was a problem hiding this comment.
lovely.
We've never had much control over the first instatiation of a VM image before.
Can we also set the uid to 10000 here? The install_opensafely_user.sh script will DTRT if needed, but wonder if it might be worth ensuring it here first?
There was a problem hiding this comment.
I think we can, I'm going to give that a try now.
| unattended-upgrades | ||
| libpam-pwquality | ||
| # required for password changes | ||
| cracklib-runtime |
There was a problem hiding this comment.
I think this because emistest is using 24.04 image, and all our others use 22.04
Looks like cracklib-runtime is not installed in 24.04 by default.
We had the same issue in TED backend work.
There's some work here I think.
We may want to think about standardising them all on 24.04 (which means upgrading TPP in place).
Or we may want to support/test on multiple versions of ubuntu.
| @@ -0,0 +1,30 @@ | |||
| #!/bin/bash | |||
| set -euo pipefail | |||
There was a problem hiding this comment.
As per other comment, worth noting that the tests harness currently runs everything in a 22.04 image.
Ideally, we'd want to run emistest tests in 24.04 image. In practice, there's likely little that would break. But we'd want to know when it did.
There was a problem hiding this comment.
I think whilst its good to have local tests, we'll also want AMI/AWS deployed test as well? That will use 24.04, and so might cover that case well enough for now
bloodearnest
left a comment
bloodearnest
left a comment
There was a problem hiding this comment.
This is great, fits quite cleanly in the end.
The AWS side of things definitely makes this the most different backend so far from all the rest.
| @@ -0,0 +1,30 @@ | |||
| #!/bin/bash | |||
| set -euo pipefail | |||
There was a problem hiding this comment.
I think whilst its good to have local tests, we'll also want AMI/AWS deployed test as well? That will use 24.04, and so might cover that case well enough for now
2 participants
Adds packer configuration at backends/emistest/packer/emis-base.pkr.hcl which defines the steps required to build both an EC2 AMI and a vagrant test box.
It defines 2 sources, emis-base, which uses the amazon-ebs builder, and contains the information needed to build an AMI, and emis-test, which uses the vagrant builder. Builds should be run through the just packer-build-aws/vagrant recipes, which specify an -only parameter and will build the specified source only.
As much as possible, the 2 sources do the same things, so we can use the vagrant source to test the provisioning.
It also runs using the same just commands and scripts as all the other backends as much as possible. The first step in the provisioning clones this repo using the specified branch, so that commands can be run from within the /srv/backend-server dir, as for any other backend.
It has 2 additional custom scripts:
Note that cloud-init files are not copied over for the aws source, they'll be used at instance launch.
We also define different cloud-init config for vagrant and aws. In the aws cloud-init user-date, as an example, we fetch some test (secureString) secrets from aws parameter store and use it to populate a value in an env file. This will get run when we launch an ec2 instance from this AMI.