ck8s-starter-nodejs's Introduction

Compliant Kubernetes Starter Kit for NodeJS

How to I deploy my application?

Click on Use this template.
Change DOMAIN to what you got from your platform admin.
Create an environment development, and set DOCKER_PASSWORD and KUBECONFIG_CONTENTS environment secrets to what you got from your platform admin.
Done!

How do I access my application?

Check the logs of GitHub Actions.

Where do I find my application logs?

Check the logs of GitHub Actions.

How do I set up alerts for my application?

Once you found you logs, check out log-based alerts.

I need help

Send the full output of your CI/CD pipeline to your TAM.

ck8s-starter-nodejs's People

Contributors

Watchers

ck8s-starter-nodejs's Issues

Various issues

The README should mention that the APP_DOMAIN must also be updated.
Creating a new repo from this template, for some reason known only to GitHub itself, prevents me from getting the Environments part of the Project Settings. So I can't actually use an Environment with my GitHub Actions.
If I follow the official instructions and RBAC rules that are suggested for CI/CD ServiceAccounts, my workflow fails, because it's not allowed to list Nodes. Workaround: just list the Pods instead, I guess?
...it also can't list certificates.
To make this super friendly to new users, we should list all the steps:
- Make a new repo from this template.
- Make a new project in Harbor to host the images.
- Export the Image Pull Secret into the default ServiceAccount as per instructions so deployment can succeed.
- Change the values here in the workflow definition file as per instructions, including APP_DOMAIN (or just put them as encrypted secrets, because WHO CARES if they are encrypted or not -- they are not supposed to change, anyway).
- Put the Docker password here as a Secret in the GitHub Project Settings.
- Put the KUBECONFIG here as a Secret in the GitHub Project Settings.

I may add comments to this issue with more as it comes up.

Tagging strategy for automated releases

This is entering almost the philosophical realm now: if I don't change anything about my application (it's still v1.11.3 as far as my features are concerned), but I do rebuild the image to pull in new dependencies and avoid vulnerabilities in the base image, something needs to still trigger a redeployment.

If we would always have ${GITHUB_REF}-${GITHUB_SHA}, simply restarting the workflow will do what I want in that case.

That's how I've kept it in the first pull request for this repo, which I am about to make.

Originally posted by @llarsson in #1 (comment)

Recommend Projects