theme: Next, 3

The Cloud

MSSE 2017

Goals

• Brief overview of cloud providers, strategies, and technologies
• Overview of deployment choices and tools
• Attempt to get our Docker image up and running in Kubernetes

Lots of different cloud providers

• AWS/Google/Rackspace/Heroku
• Each have their own way of managing systems - although there is general inter lap
• Each Cloud Service Provider has many of the same options:
  • CDN
  • Datastore
  • Object store
  • Load Balancers

Common concepts of distributed computing

• Front door proxy - Could be ssh termination - proxy from public url to load balancers
  • Can serve as caching layer
• Load balancers - Distribute load to back ends

Service discovery

• System that responds to new services, writes all available services in a service registry
• Other services can see what is available from the registry

Virtual Machines

• Virtual machines managed by a cloud provider
• Each contains the entire OS and has it’s own cpu, memory, and hard disk
• Good for things that require state - Database, Cache
• Have different performance specifications and price points

Containers

• Similar to Docker containers (may be docker containers)
• Run in a “cluster” of VMs which provide a pool of CPU and Memory options
  • All details are abstracted away
• Popular choices Mesos / Kubernetes

Tools for building/deploying to VMs

Spinnaker

• Global continuous platform
• Cloud agnostic
• Layer on top of Cloud
  • Can see your applications add/remove
  • Specify scaling policy
  • Terminate machines, see IPs

Tools for building/deploying to VMs

Packer

• Can create images of AWS VMs with your applications on them
• “Bake Process” - Take your application and turn it into a VM image
• In Amazon these images are referred to as AMIs (Amazon Machine Images)

Workflow for Spinnaker/Packer Deployment

• Commit feature
• Versioned artifacts pushed to some repository
• Jenkins has a packer job that builds a machine image and stores to a repository
• That image can be deployed via Spinnaker

Kubernetes

• Google product
• Runs in Google’s Cloud platform
• Can also run your own instance - Minikube
• Could also start up instance in AWS
• Works extremely well with docker

Kubectl

• Main cli for interacting with Kubernetes
• Possible to switch contexts between data-centers
• Can see pods/services/ingress
• Makes it very simple to manage all of Kubernetes

Kubernetes concepts

• Namespaces to organize clusters
• Clusters are a pool of VMs with a specific CPU and Memory footprint
• “Pods” are applications that run in the cluster

Pods

• Application that runs in a namespace - defined by some image
• Generally stateless
• Can be N replicas or copies
• Each Pod has a definition that defines CPU and Memory allocation
• Pods have a health check - if it does not pass Kubernetes will destroy the pod and replace with another
• Access to pods defined by a Load Balancer or Service

Running our application in Kubernetes

• Need a Google Cloud account (beware, this will eventually cost money)

• Install gcloud and kubectl

• Alternative (can do the same thing with Minikube for free)

Tagging

• Creates a tag with a format that google will allow:
  • $GOOGLE_REGION/$PROJECT_NAME/$IMAGE

docker tag ubuntu us.gcr.io/crucial-cabinet-133423/ubuntu

Push Image

• Push the Image to Google Cloud

gcloud docker -- push us.gcr.io/crucial-cabinet-133423/ubuntu

Create a cluster and run

• Create a cluster
• Tell Kubernetes to deploy to the cluster

• Expose the port via LoadBalancer

• If using Google Cloud

gcloud container clusters create example-cluster

• If using Mikikube

minikube start

Running cont.

• Same with either approach

kubectl run msse --image=us.gcr.io/crucial-cabinet-133423/msse:latest --port=8080
kubectl expose deployment msse --type="LoadBalancer"

kubectl get services

Running in Kubernetes

• Three main components
  • Deployment
  • Service
  • Ingress
• Can then create a deployment from anywhere, so long as Kubernetes has the proper context

Deployment

• Defines what to deploy
• Can define how many pods you needs
• Can specify rollback criteria

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

Service

• Allow pods to talk to each other
• Act as a load balancer and service discovery
• Interact directly with Ingress

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

Ingress

• Entry point from web to service
• Exposes your application to the outside world

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test-ingress
spec:
  rules:
  - http:
      paths:
      - path: /testpath
        backend:
          serviceName: test
          servicePort: 80