Reputation: 593
I am playing with Docker
, Kubernetes
, Google Cloud Platform(GCP)
and Gitlab
recently to achieve CI/CD
from commit
to staging
.
So far I have succeeded testing
, building
and pushing
the image to Container registry of Gitlab
.
I have a small node and docker application which output 'Hello world'
. Also, I have built my docker image in Container registry of Gitlab
. At this moment the process is docker-in-docker. I want to push my image from Gitlab container registry
to Kubernetes engine
in GCP. I have installed both kubectl
and gcloud sdk
. The Auto DevOps seems to be promising but I want to implement my own .gitlab-ci.yml
file.
Here is my .gitlab-ci.yml
below:
stages:
- testing
- build
- staging
variables:
CONTAINER_TEST_IMAGE: registry.gitlab.com/surajneupane55/node-app-
testing
CONTAINER_RELEASE_IMAGE: registry.gitlab.com/surajneupane55/node-
app-testing:latest
test:
stage: testing
image: node:boron
script:
- npm install
- npm test
build_image:
stage: build
only: [master]
image: docker:git
services:
- docker:dind
script:
- docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN
registry.gitlab.com/surajneupane55
- docker build -t $CONTAINER_TEST_IMAGE .
- docker push $CONTAINER_TEST_IMAGE
staging_site:
//I need help here!!!
//For staging my project in Kubernetes cluster in GCP
//Already created node-app Kubernetes cluster
Please, let me know if my approach is wrong since this is my first learning project with CI/CD.
Upvotes: 3
Views: 3092
Reputation: 6912
You can decouple your configuration from CI to make it more reliable and secure if you follow the GitOps approach.
Please take a look at my answer to another very similar question.
For a more high-level overview, see also:
Disclaimer: I am a Kubernetes contributor and Weaveworks employee. We build open-source and commercial tools that help people to get to production with Kubernetes sooner.
Upvotes: 0
Reputation: 593
A simple gitlab-ci.yml
file to build and deploy in GKE with Google Container Registry(GCR)
. First, we build image and push it to GCR. With valid credentials, we can easily connect the GKE with GCR and deploy.
stages:
- build
- deploy
variables:
CONTAINER_TEST_IMAGE: gcr.io/node-testing-189614/node-testing:latest
build_image:
stage: build
only: [master]
image: google/cloud-sdk
services:
- docker:dind
script:
- echo "$GOOGLE_KEY_SECRET" > key.json # Google Cloud service accounts
- gcloud auth activate-service-account --key-file key.json
- gcloud config set project node-testing-189614
- gcloud container builds submit -t $CONTAINER_TEST_IMAGE .
deploy_staging:
image: google/cloud-sdk
stage: deploy
script:
- echo "$GOOGLE_KEY_SECRET" > key.json # Google Cloud service accounts
- gcloud auth activate-service-account --key-file key.json
- gcloud config set project node-testing-189614
- gcloud config set compute/zone europe-west1-b
- gcloud config set container/use_client_certificate True
- gcloud container clusters get-credentials node-testing
- kubectl delete pods --all
- kubectl apply -f staging.yml
environment:
name: staging
url: http://***.***.**.***:****/ //External IP from Kubernetes
only:
- master
Above we delete pods in GKE because we always want to update the image with the latest tag. The best possible solution available so far is to delete the pods and let the staging.yml
file creates new one if not available.
Finally staging.yml
looks like this:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: node-testing
spec:
replicas: 2
template:
metadata:
labels:
app: node-testing
spec:
containers:
- name: node-testing
image: gcr.io/node-testing-189614/node-testing:latest
imagePullPolicy: Always
ports:
- containerPort: 8080
imagePullSecrets:
- name: gcr.io/node-testing-189614/node-testing
Upvotes: 6
Reputation: 22874
Yu do not need the image to actualy be stored in GCR to be able to use it in your GKE, although having it nearby is nice. You need a service account on gcloud so that you have a non expiring auth to GCR (or you need to use gcloud cli to auth to GCR) then just tag the image and push it.
Running it on kubernetes is a different story, and I strongly encurage you to also look at Helm for creating installation charts for your application that can be reused for multiple environments.
Upvotes: 0