The CI/CD and DevOps Blog

Kubernetes Tutorial: how to pull a private docker image in a pod

Docker images that comprise a production application are often deployed to private repositories in Docker registries. Kubernetes provides a feature called imagePullSecrets that allows pods to pull private docker images. In this blog, we demonstrate how you can easily hookup imagePullSecrets to your pod using Shippable.

 

Creating an imagePullSecrets secret

imagePullSecrets is a type of a Kubernete Secret whose sole purpose is to pull private images from a Docker registry. It allows you to specify the Url of the docker registry, credentials for logging in and the image name of your private docker image.

There are two ways an imagePullSecrets can be created.

1. kubectl create secret docker-registry command. We use this approach in our blog.

ambarishs-MacBook-Pro:gke ambarish$ kubectl create secret docker-registry private-registry-key --docker-username="devopsrecipes" --docker-password="xxxxxx" --docker-email="username@example.com" --docker-server="https://index.docker.io/v1/"
secret "private-registry-key" created

 

2. Creating the secret via a yml.

In this approach, a config.json file is created for the private registry. Its contents are then base64 encoded and specified in the .dockerconfigjson property.

apiVersion: v1
kind: Secret
metadata:
  name: private-registry-key
  namespace: default
data:
  .dockerconfigjson: UmVhbGx5IHJlYWxseSByZWVlZWVlZWVlZWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx5eXl5eXl5eXl5eXl5eXl5eXl5eSBsbGxsbGxsbGxsbGxsbG9vb29vb29vb29vb29vb29vb29vb29vb29vb25ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==
type: kubernetes.io/dockerconfigjson

 

Kubernetes Tutorial: Using Secrets In Your Application

Applications deployed to a Kubernetes cluster often need access to sensitive information such as credentials to access a database and authentication tokens to make authenticated API calls to services. Kubernetes allows you to specify such sensitive information cleanly in an object called a Secret. This avoids putting sensitive data in a Pod defintion or a docker image. In this blog, we demonstrate how you can easily hookup Kubernetes Secrets to your pod using Shippable.

 

Creating a Kubernetes Secret

Secrets are defined in a yml file in a Secret object. A Secret object can specifiy multiple secrets in name-value pairs. Each secret has to be base64 encoded before specifying it in the yml.

Let's define an API token as a secret for a fake token xxx-xxx-xxx.

1. Base 64 encode the token.

ambarishs-MacBook-Pro:sources ambarish$ echo -n "xxx-xxx-xxx" | base64
eHh4LXh4eC14eHg=

2. Create the secrets yml called create-secret.yml.

apiVersion: v1
kind: Secret
metadata:
  name: auth-token-secret
type: Opaque
data:
  AUTH_TOKEN_VALUE: eHh4LXh4eC14eHg=

3. Create the secret in the kubernetes cluster using kubectl.

$ kubectl create -f secrets.yml
secret "auth-token" created

Kubernetes Tutorial: Attaching A Volume Mount To Your Application

Kubernetes allows you to package multiple containers into a pod. All containers in the pod run on the same Nodeshare the IP address and port space, and can find each other via localhost. To share data between pods, Kubernetes has an abstraction called Volumes. In this blog, we demonstrate how you can  easily hookup Kubernetes Volumnes to your pod and define the containers in the pod using Shippable.

 

Kuberetes Volumes

A Volume is a directory with data that is accessible to all containers running in a pod and gets mounted into each containers filesystem. Its lifetime is identical to the lifetime of the pod. Decoupling the volume lifetime from the container lifetime allows the volume to persist across container crashes and restarts. Volumes further can be backed by host's filesystem, by persistent block storage volumes such as AWS EBS or a distributed file system. The complete list of the different types of volumes that Kubernetes supports can be found here.

Shippable supports mounting all the types of volumes that Kubernetes supports via the dockerOptions resource. However, the specific volume type that we demonstrate in this blog is a gitRepo volume. A gitRepo volume mounts a directory into each containers filesystem and clones a git repository into it. 

The Difference Between CI Pipelines and DevOps Assembly Lines

What's in a name? wrote the greatest Bard that ever lived.

He was wrong. If someone ever asked me a hypothetical question about which dead person I'd want to have a conversation with, it'll definitely be Shakespeare. Let me explain why.

When we launched Shippable Pipelines last year, we wanted to highlight the difference between plain vanilla CI and the capability to put together a deployment "pipeline" that spans orchestration across multiple environments and supports all tasks involved in software delivery like CI, infrastructure provisioning, test automation, deployments, security patching, release management, config mgmt, service discovery, etc. 

However, shortly after we launched, other CI providers launched their own interpretations of "pipelines"! For example,

How did everyone come to the same exact place so rapidly? As we found out, they didn't. Pipelines was being used as a fancy name for CI, with features that Shippable had supported for over two years, like Matrix builds for splitting tests or testing against multiple environments for example. 

We needed a way to explain why Shippable is different. This blog explains why we landed on DevOps Assembly Lines as the perfect way to describe our approach to DevOps and CI/CD. 

Q&A with Adrian Mouat, author Of 'Using Docker'

Our very own Pavan Belagatti recently chatted with Adrian Mouat, the author of Using Docker. Read on about what he has to say about the book, the future of Docker, and DevOps...
 
 
[Pavan] Hey Adrian, thanks for taking the time to chat with us. Can you introduce yourself to our audience?
[Adrian] I work for a company called Container Solutions whose mission help companies transition to the new "cloud native" world of containers, orchestrators and microservices. My title is "Chief Scientist" which means I'm responsible for investigating and developing software designed to help companies adopting cloud native. A lot of my time is also taken up providing training and speaking about cloud native technologies such as Docker.
 
[Pavan] When did you become passionate about Docker? What is the story behind it?
[Adrian] At a previous company, we started using Docker and running a Docker meetup, where we realised its huge potential. It enabled us to rapidly iterate on a few projects we were playing with, which would have taken far longer with VMs or other approaches.