kube-workflow
Advanced tools
Call it in review, preprod, and prod github workflows
.github/workflow/review.yaml
- uses: SocialGouv/kube-workflow@master
with:
environment: dev
token: ${{ secrets.GITHUB_TOKEN }}
kubeconfig: ${{ secrets.KUBECONFIG }}
rancherProjectId: ${{ secrets.RANCHER_PROJECT_ID }}
rancherProjectName: ${{ secrets.RANCHER_PROJECT_NAME }}
# components: app hasura
.kube-workflow/common/values.yaml
# here you define variables shared by all helm subcharts/components
global: {}
# here you can configure components values
app:
enabled: true # enable each component
containerPort: 3000
Here is the order, the last in the list is the last applied:
From kube-workflow repository:
$KUBEWORKFLOW_ACTION/charts/$COMPONENT/values.yaml (the defaults)From your project repository:
.kube-workflow/common/values.yaml.kube-workflow/env/$ENVIRONMENT/values.yamlsee kube manifests for your project directory
npx kube-workflow b -so
get documentation of kube-workflow cli
npx kube-workflow --help
npx kube-workflow b --help
pre-requisites:
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh" | bash
To see all components availables go to charts folder:
To see all availables options by component see each chart's values.yaml file:
You can declare as many instances as you want of a component, the name must start with the chart's name suffixed by -, eg:
app:
enabled: true
host: ozensemble.fr
redirectFrom:
- "{{ .Values.global.host }}"
- www.ozensemble.fr
app-2nd-instance:
enabled: true
probesPath: /healthz
envFrom:
- secretRef:
name: "{{ .Values.global.pgSecretName }}"
- secretRef:
name: app-sealed-secret
- configMapRef:
name: app-configmap
The component called "jobs" is a special component that allow you to define a full pipeline:
hasura:
needs: [db]
jobs:
enabled: true
runs:
- name: db
# use: ./.kube-workflow/jobs/create-db # local job, defined in project repository
# use: https://github.com/SocialGouv/kube-workflow/jobs/create-db # degit full url
use: SocialGouv/kube-workflow/jobs/create-db # degit implicit github
with:
pgAdminSecretRefName: pg-scaleway
see jobs/create-db/use.yaml for full example.
All vues from runs keys will be interpolated in the job, but you can also uses all parameters directly, except the with parameter that is reserved to be used with use and inject variable to the called job.
All others components can declare dependencies on jobs using the needs key, and all jobs can declare depencencies on other jobs and other components too, using instances names.
Mains jobs parameters are:
use and with: to include job definition from elsewhere, usage can be recursive (job can use job, that can use job etc...)image the docker image file that will run the job (default is debian for now, in future this will be a generic image with almost all needed tooling)action repository (or subfolder in a repository) that will be degitted in mountpoint /action/ in the job execitionrun a custom command that will override docker image default run, can be a full bash script or just a call to a commandcheckout (default true), this enable the degit of the repository at current commit in mountpoint /workspace/ in the jobThere is a shared storage volume between jobs of a same pipeline, it's mounted at /workflow/ in the job execution, you can share artifacts between jobs in this directory.
Same as other components, you can define multiple instance of jobs, for example, if you want to use one pipeline from a manual triggered action.
Every yaml file in .kube-workflow/common/templates will be merged with the helm Chart templates folder before the build.
All theses files can use the Helm templating syntax (or not if you don't need it, helm template is a superset of yaml).
Both extensions yaml and yml are accepted.
Every yaml files in .kube-workflow/env/$ENVIRONMENT/templates will be merged with the helm Chart templates folder before the build, according to the environment input (dev | preprod | prod).
All theses files can use the Helm templating syntax.
Usually, that's where you put your ConfigMap and SealedSecrets ressources.
The kustomization patches are applied after Helm template rendering.
The kustomization entrypoint is $KUBEWORKFLOW_ACTION/env/$ENVIRONMENT/kustomization.yaml.
To override it, create a file called .kube-workflow/env/$ENVIRONMENT/kustomization.yaml in your project and containing:
resources:
- ../../common
patches:
# ... put your patches here
By doing this way you just optouted from generic kustomization for the selected environment.
If you want (and more often you want) to keep the generic kustomization, containing some infra logic defined by the advised SRE team, you can extends it like this.
resources:
- ../../common.autodevops
patches:
# ... put your patches here
You can do it as well for the common base file called by environment kustomizations, just add a file called .kube-workflow/common/kustomization.yaml in your project and containing:
resources:
# - ../base # here is if you want to optout
- ../common.autodevops # here is if you want to extends from autodevops default settings
patches:
- target:
kind: Ingress
patch: |
- op: add
path: "/metadata/annotations~1nginx.ingress.kubernetes.io~1configuration-snippet"
value: |
more_set_headers "Content-Security-Policy: default-src 'none'; connect-src 'self' https://*.gouv.fr; font-src 'self'; img-src 'self'; prefetch-src 'self' https://*.gouv.fr; script-src 'self' https://*.gouv.fr; frame-src 'self' https://*.gouv.fr; style-src 'self' 'unsafe-inline'";
more_set_headers "X-Frame-Options: deny";
more_set_headers "X-XSS-Protection: 1; mode=block";
more_set_headers "X-Content-Type-Options: nosniff";
If you think you patches can be reused by other project, contribute to common/patches and env/*/patches folders of the action by sharing them.
All charts are published and released as a chart repository at https://socialgouv.github.io/kube-workflow/.
You can use it in your Chart.yaml as:
dependencies:
- repository: https://socialgouv.github.io/kube-workflow/
name: kube-workflow
version: "1"
kube-workflow is the "umbrella hcart" (the main chart in helm jargon), it contain namespace, psp and all others components as subcharts, you can call all components from subkeys in your values, global remain at top.
Releasing follow semantic versioning using standard-version tool. Versioning is volountary trigerred manually on dev machine too not block rapid iteration of master branch code.
Just run yarn release on master branch and CHANGELOG will be feeded with informations from commits using the conventionnal commit standard, then package will be bumped, as the charts versions and commited, then tagged. Then just follow cli instruction that say: git push --follow-tags.
Then the action will publish automatically new version of npm cli, and charts index.
all directories added to tests/samples are like a .kube-workflow directory in a project, it will be automatically tested when you will run yarn test.
To run only one test at once you can run yarn test -t name-of-my-test.
To upgrade snapshots run yarn test -u.
New charts are welcome in folder charts/. More options on existing charts will be carefully design, in case of doubt, or if you don't want to wait, you can hack everything using kustomize from your repository. Feel free, then give us feedback to ensure we follow best practices and are preserving project maintainability.
Wee need:
New patches are welcome in folders common/patches/ and env/*/patches/
New jobs are welcome in folder jobs/
wee need:
to enable correct syntax recognition and coloration of yaml helm templates in vscode, enable Kubenernetes extension
Resources:
FAQs
Unknown package
The npm package kube-workflow receives a total of 8 weekly downloads. As such, kube-workflow popularity was classified as not popular.
We found that kube-workflow demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Research
A malicious npm package disguised as a WhatsApp client is exploiting authentication flows with a remote kill switch to exfiltrate data and destroy files.
Security News
PyPI now supports digital attestations, enhancing security and trust by allowing package maintainers to verify the authenticity of Python packages.
Security News
GitHub removed 27 malicious pull requests attempting to inject harmful code across multiple open source repositories, in another round of low-effort attacks.