DEV Community: coktopus

Candlestick with React & Recharts

coktopus — Mon, 05 Oct 2020 09:14:10 +0000

My experience with Recharts

Easy & quick
Not too bulky
Typescript support
Lots of alternative way to overcome bugs
And most important works well with pdf generations

Quick Example

Candlestick with error-bar.
jsfiddle

Automation of helm | step 5

coktopus — Mon, 28 Sep 2020 06:09:27 +0000

To automate helm deployment we a need circleCI configuration.

BRANCH FILTER

workflow provides an option to filter the branches on which the circleCI pipeline runs:

DEV

workflows:
  main:
    jobs:
      - deploy:
          filters:
            branches:
              only: 
                [project-for-video-dev]

PROD

workflows:
  main:
    jobs:
      - deploy:
          filters:
            branches:
              only: 
                [project-for-video-prod]

ORBS

gcp-gke is use to interact with kubernetes engine running in gcloud. It have commands like create-cluster, delete-cluster, and so on . we use rollout-image which updates the deployment with latest image.
gcp-gcr has built in commands and gcr-auth is use to authenticate the user and it will take the credentials from environment variables of circleCI.

All the images stored in Google Container Registry is a perfectly working image and ready to deploy on environment . so replace the current tag running tag with the newer one in config.yml and push it to repository and merge it to the branch which triggers the circleCI pipeline and circleCI is already setup to run rollout-image command.

EXAMPLE

dev branch contains config.yml file and all the values required to update dev. If any tag will merged to dev branch it will trigger the pipeline and update the dev-deployment with the newly merged tag of image and same in the case of other branches like prod.

KUBERNETES PROCESS

Once the pipeline is triggered, the kubernetes run their blue-green deployment process and update the image with zero down time.

Helm Explained | step 4

coktopus — Mon, 21 Sep 2020 05:48:32 +0000

Helm is a tool that streamlines installing and managing Kubernetes applications. Think of it like yum and homebrew for Kubernetes. Helm uses a packaging format called charts. A chart is a collection of files that describe a related set of Kubernetes resources. helm provide commands to install, run, update deployments and services.

CONCEPT OF TILLERS

Tiller, the server portion of Helm, typically runs inside of your Kubernetes cluster. But for development, it can also be run locally, and configured to talk to a remote Kubernetes cluster.

In Helm v3 tiller is gone, and there is only Helm client.

UNDERSTANDING HELM CHARTS

Helm uses a packaging format called charts. A chart is a collection of files that describe a related set of Kubernetes resources. A single chart might be used to deploy something simple or a full web app stack with HTTP servers, databases, caches, and so on.

Templates generate manifest files, which are YAML-formatted resource descriptions that Kubernetes can understand. We'll look at how templates are structured, how they can be used.

To build a helm chart helm create is the command. It creates the base template of YAML files and the base template can be modified in the way you want and you can find Kubernetes-ready app at helm-hub and can push you own created helm chart.

Because we are using GKE helm and kubectl is already setup and ready to use otherwise, needs to setup by installing. Deployment and Services of Google Kubernetes Engine are the features which are getting used in in the setup.

development .yaml contains all the details of development and service.yaml contains the details which expose the development and these files are getting their values like image, tag, and ports from value.yaml.

Few tags from *value.yaml*

replicaCount: 1

image:
  repository: gcr.io/project-for-video/project-for-video
  pullPolicy: Always
  # Overrides the image tag whose default is the chart appVersion.
  tag: "latest"

containerPort: 3100
readinessProbe: /
livenessProbe: /

serviceAccount:
  name: "project-for-video-dev"

service:
  type: LoadBalancer
  port: 80
  targetPort: 3100
  nodePort: 30001

Namespaces are intended for use in environments with many users spread across multiple teams, or projects. ... Namespaces are a way to divide cluster resources between multiple users (via resource quota). In future versions of Kubernetes, objects in the same **namespace will have the same access control policies by default.

DEPLOY CHART TO GKE

Create helm chart with helm create {name of chart} command
Updates the values in value.yaml. Update the name, image, image tag, container-port, service port, and internal port(target port)
Push it to the separate repository with separate branches like dev for dev-environment and prod for prod-environment
prod branch

dev branch

Create namespaces kubectl create namespace {NAMESPACE}
Clone repository on cloud.
1. Install chart.(from both branches dev and prod because the ports are different) helm install {name-of-chart} {address-of-chart} --namespace {NAMESPACE}
Test (postman to check the response)

IMPORTANT COMMANDS

helm cerete {NAME OF CHART}
helm delete {NAME OF CHART}
helm update{NAME OF CHART}
helm rollback It only updates if there is any change in chart
kubectl get namespace --all
kubectl create namespace
kubectl delete namespace

How circleCI fits into the setup | step 3

coktopus — Mon, 14 Sep 2020 05:36:48 +0000

CircleCI is a tool to handle the continuous integration and continuous development.

Basically, Continuous Integration means multiple developers pushing small, frequent changes to a shared repository or ‘master’. They are integrating changes continuously, rather than periodically.

Because the CD is a periodic process and CI is not the CD is getting handled separately.

How does CircleCI helps?

CIrcleCI provides simple integration to code repositories like github and bitbucket

It automatically run the circleCI pipeline when triggered by merges.

Notification of everything happening on the attached circleCI's

Build all jobs within one circle.yml file.

No need to manage server as every job will be started on new environment.

Web UI is truly interactive and improving frequently

To attach repositories

Thanks to role set access control based on SSH key, because It is important when working as an organization.

`circle.yml` explained

Add a folder '.cirlceci', create 'config.yml', and push it to the repository to active the triggers of repository attached to circleCI

Points to understand

workflow (lines 30-37) - runs the jobs in a sequence
jobs (lines 5-28) - The jobs level contains a collection of arbitrarily named children. build is the first named child in the jobs
filter (lines 35-37) - pipeline only triggers when a request is merged in the listed branch
build (lines 6-16) - Boilerplate kind of jobs
steps (lines 20-28) - actual commands run in a sequence as it is declared
orbs - explained below

Importance of orbs

Orbs is reusable package of YAML configuration that contains repeated pieces of config into a single line of code. CircleCI orbs are open-source, shareable packages of reusable configuration elements, including jobs, commands, and executors.

orbs save a lot of extra efforts and time. The Orb Registry is an open repository of all published orbs

In config.yml from line 12-21 all the steps are the command of the orbs.

node, gcp-gcr, gcp-gke, helm are the orbs which are getting used in the setup.

gcp-gcr . An orb for working with Google Container Registry . gcr/gcr-auth is authentication to google container registry and it fetch the credentials from circleCI environment variable. Environment variable will not get exposed throughout, the execution of pipeline which indicate that sensitive data can be store inside.

Environment Variables

The target of this part of setup is to store all the unique tags of images in google container registry with the help of CIRCLE_SHA1 which is unique commit id and those tags were further use to update the deployment.

video link is there for the whole implementation

Understanding Docker step-2

coktopus — Sun, 06 Sep 2020 08:10:57 +0000

Explain

Docker is all about containerization. It is an open-source project used to run containerized applications.

Containers are isolated platform in which applications run independently.

All the dependencies, npms, environment variables, network ports or anything required to run the application can be added to the container with the help of Dockerfile to run the docker images which is the build image of the application.

The application running in the container can be accessed from outside the container if exposed.

FROM node:11.8.0-alpine

WORKDIR */usr/src/app*

COPY *package.json* *.*

RUN *npm* *install*

copy *.* *.*

EXPOSE *3100*

CMD "node" "server.js"

Dockerfile is a synchronized set of command written in an easy-to-understand syntax that includes the instructions to build a Docker image.

Dockerhub is a public repository and can be used to pull and push images publicly. There are plenty of official images like node. Many private repository/registries are available and GCR is the one which is being used in this series.

To build the image:

docker build ${url of dockerfile}

To expose the application running in the container, a mapping of inter-port and external port is required.

docker run [OPTIONS] ${internal-port}:${external-port} ${IMAGE ID}

After building the image, image id will be available in images list.:

After running the container, container id will be available:

Few docker commands

'docker ps' - list of running container

'docker' - list of images

'docker run' - to run the image

'docker rm' - to remove resource image/container

'docker build' - to build for dockerfile

video of complete setup and implementation of docker

For Gcloud setup --> https://www.youtube.com/watch?v=A-3yY594Oko&t=27s

CICD in 5 steps with circle CI & helm

coktopus — Fri, 28 Aug 2020 14:38:15 +0000

CICD itself is enormous, so we just cover those section which is
sufficient to maintain the production deployment of a basic application.

CICD is the process of continuous integration and continuous delivery which means automating all the steps involved right from merging the code to updating the running environment with that code.

This setup was created to manage the deployments of my first side project and after completing and implementing the pipeline I just realized that the setup is a short and effective solution which makes me motivates to write a blog.

The series has 5 steps which are interlinked with each other.

Gcloud setup ☁️
Docker setup 🚢
Automatic build docker and push to google container registry.
Deploy helm charts 📋
Automate the update deployment process 💻

Setup gcloud

Important points

Cloud is free for a year🆓
Google Kubernetes Engine automatically creates VM instances.💻

Google Cloud projects form the basis for creating, enabling, and using all Google Cloud services including managing APIs, enabling billing, adding and removing collaborators, and managing permissions for Google Cloud resources.

Creating a cluster is the primary step inside the project.
Cluster is the set of one master node and multiple worker nodes that run the containerized applications.

Master node runs the core resource controllers and inside the worker nodes, pod runs the containers which can be 1 or more that one.

While setting up the cluster, one step will be of a machine set up in which OS image, CPU performance, and resource allocation have to be selected.

Once the cluster's setup is completed the cloud is ready to deploy applications.

The best feature of gcloud is that it provides the shell terminal in its UI, so no need to connect separately with puTTY.

gcloud init

and

gcloud auth login

are the basic commands and reference video is attached for more details.

TO BE CONTINUE...