Skip to content

Latest commit

 

History

History
114 lines (100 loc) · 4.77 KB

Readme.md

File metadata and controls

114 lines (100 loc) · 4.77 KB

Using DevSpace for manual deployment

Introduction

CI/CD of Kubernetes

Prerequisite

  • Kubernetes cluster
  • Docker image in container hub (docker hub my case)
  • YAML knowladge

Use Case

Continues Deliver and Continues integration for any project.

Research

I have some idea for simple project, where I could implement CI/CD for Kubernetes deployment. My current cluster is in private network, so it's different approach than using public cloud provider. There is internet connect for outside work. For now using Github actions to build the image, and devspace to deploy latest image from dockerhub. Need to rethink how to make it CI/CD, probably even have to choose different tool.

Try yourself

Now deploying docker image.

version: v1beta10

# `vars` specifies variables which may be used as ${VAR_NAME} in devspace.yaml
vars:
- name: REGISTRY_PASSWORD
  password: true
- name: IMAGE
  value: augustris/img

# `deployments` tells DevSpace how to deploy this project
deployments:
- name: img
  # This deployment uses `helm` but you can also define `kubectl` deployments or kustomizations
  helm:
    # We are deploying the so-called Component Chart: https://devspace.sh/component-chart/docs
    componentChart: true
    # Under `values` we can define the values for this Helm chart used during `helm install/upgrade`
    # You may also use `valuesFiles` to load values from files, e.g. valuesFiles: ["values.yaml"]
    values:
      containers:
      - image: ${IMAGE} # Use the value of our `${IMAGE}` variable here (see vars above)
        command: ["sleep"]
        args: ["9999999"]
      service:
        ports:
        - port: 3000
# `dev` only applies when you run `devspace dev`
dev:
  # `dev.ports` specifies all ports that should be forwarded while `devspace dev` is running
  # Port-forwarding lets you access your application via localhost on your local machine
  ports:
  - imageSelector: ${IMAGE} # Select the Pod that runs our `${IMAGE}`
    forward:
    - port: 3000

  # `dev.open` tells DevSpace to open certain URLs as soon as they return HTTP status 200
  # Since we configured port-forwarding, we can use a localhost address here to access our application
  open:
  - url: http://localhost:3000

  # `dev.sync` configures a file sync between our Pods in k8s and your local project files
  sync:
  - imageSelector: ${IMAGE} # Select the Pod that runs our `${IMAGE}`
    excludePaths:
    - .git/
    uploadExcludePaths:
    - Dockerfile
    - node_modules/

  # `dev.terminal` tells DevSpace to open a terminal as a last step during `devspace dev`
  terminal:
    imageSelector: ${IMAGE} # Select the Pod that runs our `${IMAGE}`
    # With this optional `command` we can tell DevSpace to run a script when opening the terminal
    # This is often useful to display help info for new users or perform initial tasks (e.g. installing dependencies)
    # DevSpace has generated an example ./devspace_start.sh file in your local project - Feel free to customize it!
    command:
    - ./devspace_start.sh

  # Since our Helm charts and manifests deployments are often optimized for production,
  # DevSpace let's you swap out Pods dynamically to get a better dev environment
  replacePods:
  - imageSelector: ${IMAGE} # Select the Pod that runs our `${IMAGE}`
    # Since the `${IMAGE}` used to start our main application pod may be distroless or not have any dev tooling, let's replace it with a dev-optimized image
    # DevSpace provides a sample image here but you can use any image for your specific needs
    replaceImage: loftsh/javascript:latest
    # Besides replacing the container image, let's also apply some patches to the `spec` of our Pod
    # We are overwriting `command` + `args` for the first container in our selected Pod, so it starts with `sleep 9999999`
    # Using `sleep 9999999` as PID 1 (instead of the regular ENTRYPOINT), allows you to start the application manually
    patches:
    - op: replace
      path: spec.containers[0].command
      value:
      - sleep
    - op: replace
      path: spec.containers[0].args
      value:
      - "9999999"
    - op: remove
      path: spec.containers[0].securityContext

# `profiles` lets you modify the config above for different environments (e.g. dev vs production)
profiles:
  # This profile is called `production` and you can use it for example using: devspace deploy -p production
  # We generally recommend to use the base config without any profiles as optimized for development (e.g. image build+push is disabled)
- name: production
# This profile adds our image to the config so that DevSpace will build, tag and push our image before the deployment
  merge:
    images:
      app:
        image: ${IMAGE} # Use the value of our `${IMAGE}` variable here (see vars above)
        dockerfile: ./Dockerfile

It works properly, but have to find more automatic way.