Skip to content

Latest commit

 

History

History
52 lines (35 loc) · 1.81 KB

04-cd.md

File metadata and controls

52 lines (35 loc) · 1.81 KB
Raw

Cut out the boring stuff

Every time that release time comes around, you get uncomfortable. You do not feel safe about deploying to production. Deploying by hand always feels like that nothing is entirely the same each time.

Guess it's time to script continuous delivery?

Hint: If you already know how to run your application on the server, it should be no different getting GH Actions to do it for you, as it is, in fact, executing on the server!

Task

  • Take your kubeconfig file and put it as a secret in your repository.
  • Create a script that persists the kubeconfig file to disk, and then deploys your application to Kubernetes
  • OPTIONAL: Augment your script such that you can deploy multiple versions ( eg. development, staging, production ), depending on the PR branch name

Hint: You can use the kubectl command to apply your manifests.

Implementation hint:

On your workstation, run:

cat ~/.kube/config | base64 -w0
  • Take the output and put it in a secret in your repository, called KUBECONFIG.
  • In your workflow, you can then do:
      - run: echo "${{ secrets.KUBECONFIG }}" | base64 -d > kubeconfig
      - run: kubectl --kubeconfig kubeconfig <your kubectl commands>

The --kubeconfig flag tells kubectl to use the kubeconfig file you just created.

You can have multiple kubeconfig files, and use the --kubeconfig flag to switch between them, to emulate differnet environments.

Extra: Vulnerability Concerns

Your workflow now executes code on the server. You're in a public repository, because you've forked one, meaning that, anyone can fork your repository as well.

If you fork a repository, you can make changes, and pull-requests, and oh no... execute arbitrary code on your server? 😱

  • Look into the Settings / Actions and discus why this is/is not a problem.