K
Q

What's the idiomatic way to move a go binary into a pod before helm install?

8/14/2019

I use CircleCI to build a go binary that I want to run in a pod installed by Helm charts. I want to move the binary from CircleCI to the remote cluster so it's available when the pod starts. I know it's possible with volumes, like ConfigMap or Secrets but I'm not sure what the best way to do this.

I once made it work with a private docker registry and a kubernetes Secrets for the credentials of the registry but I don't like this option. I don't want to have to build and push a new docker image on every binary change.

version: 2.1
jobs:
  build_and_deploy:
    docker:
      - image: circleci/golang:1.12.7
    steps:
      - checkout
      - run: go get -v -t -d ./...
      - run: go build cmd/main.go
      - run: ...
      - run: helm install

workflows:
  version: 2
  build:
    jobs:
      - build_and_deploy:

The expected result should be a new binary available on the cluster every time the job runs.

-- mathieux51
circleci
docker
go
kubernetes
kubernetes-helm

Similar Questions

Route the output of model A as the input of model B on Seldon Core
Docker from windows is unable to pull images from my private registry once Kubernetes is enabled
Disabling cronjob in Kubernetes when occur failed status
The server doesn't respond anymore after I switch framework Gin to Echo
Python conflicts in composer crash the whole kubernetes cluster, how do I fix it?

2 Answers

8/14/2019

Your CI/CD should simply build a Docker container with that binary. Then you should push it to the private repository. Cluster should download the binary.

-- Marcin Ginszt
Source: StackOverflow
8/14/2019

According to the best practices - the binary file should be applied during your build image execution - as mentioned by community above and best developer practices:

Don’t create images from running containers – In other terms, don’t use “docker commit” to create an image. This method to create an image is not reproducible and should be completely avoided. Always use a Dockerfile or any other S2I (source-to-image) approach that is totally reproducible, and you can track changes to the Dockerfile if you store it in a source control repository (git).

However, from another point of view you can consider:

1. init contianers to build your image directly on the cluster

2. kaniko with with external location of your build context (gcs bucket git repository)

3. helm pre-install hook in order to use the above mentioned solutions

4. finally other solutions like cloud build or cloud build locally

Please refer also to "Switching from CircleCI to Google Cloud Build". As described in the article above you can use keel to automatically update your deployments when the image in the docker repository is updated.

Please let me know if it helps.

-- Hanx
Source: StackOverflow