znmeb
commented
7 years ago Cloud-init or something like it? https://cloudinit.readthedocs.io/en/latest/
Closed MikeTheCanuck closed 7 years ago
znmeb
commented
7 years ago Cloud-init or something like it? https://cloudinit.readthedocs.io/en/latest/
pdxdiver
commented
7 years ago This is done. See https://github.com/hackoregon/backend-service-pattern
As mentioned in #28, the solution for keeping secrets out of our GitHub repo seems to boil down to configuring them in Travis env vars.
Background
Once we bake the secrets (such as db_password) into the container image, the challenge is where to push that container image so that the secrets don't get published [in the container image] to the world in a public registry.
Possible solution
One tantalizing solution is to use a private registry, such as AWS EC2 Container Registry (aka AWS ECR). If Hack Oregon is going to build all its infrastructure in AWS, ECR seems as good as any, especially since it appears that as long as we stick to one region, there's no charge for storage or data in or out: https://aws.amazon.com/ecr/pricing/ http://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html
With a private registry, we don't have to worry about anyone except those with authorization to be able to pull down containers locally. That AWS ECR authorization token will certainly be limited to those setting up Travis repos for each project.
Alternative: can container images be pushed directly from Travis to AWS ECS?
If we can push container images straight from Travis directly to AWS ECS, then we wouldn't even have to worry about a registry at all (at least for this scenario). But is that even possible? Is it simply a matter of a few different commands in /bin/docker-push.sh? That doesn't solve other issues that may require a registry (see below), but all options should be considered here.
Other issues