Hacker News Reader

Comment by gkop | Hacker News Reader

What's the preferred workflow when continuously integrating and deploying in containers? At what step do you run your automated tests? Do you run them in the same image that will go into staging and then production? If using the same image, do you ship to staging and production with test dependencies included, or how do you strip away test dependencies first?

View on HN

There are many way to do this but we (distelli) recommend the following:

1. Run automated tests during container build (maybe in the AfterBuildSuccess step)

2. Have a single image that goes to both staging and production. Pass in environment variables or configs to operate the image differently in staging or prod

3. Don't include test dependencies in the image so the image is smaller. So if you're running tests etc don't add the tests and dependencies in the Dockerfile. Instead have your CI system run the tests.

> Instead have your CI system run the tests.

Is "your CI system" typically distelli or another vendor?

We (distelli) do provide our own CI system but you don't have to use ours. You can use your own CI system and kick off the pipeline from that.

Some of our customers use Jenkins while others use one of the many hosted CI systems.

I like the flexibility from the point of view of minimizing the initial configuration work when we already have a CI vendor in place.

To be precise - Can distelli work with GitHub's CI API so that the distelli container build kicks off only after GitHub reports a CI pass?

Yes, we can kick off a kubernetes deployment based on the pipeline rules you specify from any CI server that can make an API call to our service.

So you can use Jenkins or Gitlab CI or any other CI you like and when that system reports a CI pass we can kick off the deploy to your k8s cluster.

Thanks for explaining!

our strategy is to have two dockerfiles for each repo. The main Dockerfile and a Dockerfile-test, that builds FROM the main one and contains the test dependencies. during CI we first build from the main Dockerfile and then from the second one. since the test one builds from the main one, there is no significant overhead and it's usually a very fast build. we run the tests on the test image and if they pass, we push the main image to the tests. This means that we do not in practice, deploy the same image we test, but it's pretty close to that. It just requires some discipline to make sure that the test one just adds test dependencies and nothing more to be as similar as possible to the main one. We use circle for continuous integration but distelli looks really cool. Something that circle and travis don't give you is a pipeline feature. Having a system that is aware of your cluster technology enables some nice pipelines and better control

I'm using Circle as well. The big problem with Circle is they don't have a ready solution for caching layers across builds.

Very true. Our builds are very slow, and they could be much faster if docker caching worked properly. Seems like these issues will be solved soon with the next major release of the platform. Let's hope

The general idea is to test and develop on the same image that will go to prod. Environment-specific configuration should generally be injected at container runtime.

We use CircleCI. The build container is provisioned with docker/gcloud/kubectl. The repo webhook fires on commit, the image is built, a test entrypoint is executed on the image to run tests. If the tests pass the image is pushed to the project repository, and then kubectl is used to update the kubernetes deployments with the new image ref.

> The build container is provisioned with docker/gcloud/kubectl.

What does this mean? I thought one of the key things that Circle provides is the build container.

Yes, circle provides the build container and docker, and our scripts install gcloud and kubectl and authorize a service account that can push to the associated project image repository.

Gotcha. We're doing the same thing here. The only problem is that Circle doesn't cache the image layers, so we do a full build every time, which takes about 10 minutes.

Yep same here, that's one of the things we need to improve on to get our deploy times down.

Reply on news.ycombinator.com