stono / ci-in-a-box Goto Github PK

A big list of enforce_arg calls is not easy to manage. We should just use .env.default as a list of mandatory keys, some with values, which .env overwrittes if present.

https://github.com/Stono/ci-in-a-box/blob/master/start#L76

At the moment the kubernetes folder contains preprod and prod, really; we could be much smarter and have something like docker-compose --rm ciinabox deploy environment --name=preprod and subsequently use a terraform/environment as a template.

The script generates /etc/go-users which is used for htpasswd auth; however there is currently a manual step which requires you to go into the new go server, go into admin and set the password file path - before authentication is enabled.

Perhaps this would be fixed with a default go-config.xml

Says it all really... this repo was largely a proof of concept.

It would be nice to have a bunch of premade modules that you can deploy to a target environment. This would set up all the networking/terraform aspects and also deploy any kubernetes containers too?

For example:

• docker-compose run --rm ciinabox deploy mysql --environment=preprod
• docker-compose run --rm ciinabox deploy redis --environment=preprod

Totally stepping into the realms of cloud automation here though and there are plenty of people that do that.

Despite using the docker-letsencrypt image, we will get an invalid cert because we access docker on an IP, rather than a domain name.

If we were to make domain names part of this script (thus generating valid certs), then there would be a requirement that the user has provided proof of ownership through the GCP portal first, or the terraform scripts would fail.

Subsequently perhaps this is a toggle option, if provided; we will manage DNS entries too and generate a valid cert.

If using kubernetes Deployments for ages, when scaled/deleted and a new agent comes back up with a different host name, the old agents go into lost contact and are never cleared.

If using a statefulset (so consistent host names), the agents rejoin as the same item however we need to manually delete the agent lock file, and also any updated configuration is not applied (for example; environments).

As the agents actually build images on the underlying GKE host; and there is an image for each GO_PIPELINE_COUNTER, those images build up over time and don't get cleared.

Image Cleaner is a daemonset which fixes this problem.

It would be nice to have a default go-config.xml which has an example pipeline of build, test, deploy (preprod, prod) of https://github.com/Stono/simple-node-app, so that people can see the web sequence diagram in the readme in action.

It also would fix #4

At the moment, the cleanup script is detecting PersistentVolumes as part of PersistentVolumeClaims that are not bound, but still valid.

For example; take a StatefuleSet with a PVC Template, scale it to 3, then down to 2, and you'll still have 3 disks (valid), clenaup will delete that third disk, leaving the PVC in an invalid state.

PV's should be checked against PVC's, not just for their bound status.