Skip to content

Eeks the Cat
Compare
Choose a tag to compare
@jstange jstange released this 09 Nov 14:36
· 2432 commits to master since this release
v1.8.0
a223ede
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

ContainerCluster now supports EKS and GKE

The ContainerCluster resource now understands how to target EKS (Amazon) and has partial support for GKE (Google). Note that the EKS service only exists in us-east-1 and us-west-2 as of this writing.

Simple stack:

---
appname: ekstest
container_clusters:
- name: containers
  flavor: EKS
  instance_type: t2.medium

Complex:

---
appname: ekstest
container_clusters:
- name: k8s
  flavor: EKS
  instance_type: t2.medium
  instance_count: 4
  kubernetes:
    max_pods: 10
 instance_subnet_pref: all_public
  # This stanza is optional; normal deployments to EKS might be done with kubectl
  # or through a CI tool such as GitLab
  kubernetes_resources:
  - apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx-deployment
    spec:
      selector:
        matchLabels:
          app: nginx
      replicas: 2
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: nginx:1.8
            ports:
            - containerPort: 80

The GKE implementation is somewhat limited by our current version of the google-api-client gem, which does not support some critical API calls. We need to migrate to Chef 14, so that we can be free to update some of this gem's dependencies, before support for this can be properly completed. In the meantime, it can build and configure clusters, but not properly label them nor interact with Kubernetes directly.

GKE example:

---
appname: gketest
container_clusters:
- name: containers
  cloud: Google
  kubernetes:
    version: "1.10"
  instance_count: 2
  instance_type: n1-standard-1
  local_ssd_count: 1
  vpc:
    deploy_id: MYVPC-DEV-2018082215-VM
    vpc_name: "vpc-internet"

mu-deploy -u improvements

Updating an existing stack will now invoke the groom method correctly on more resource types, notably ServerPools. Re-grooming a stack with an Autoscale group will now update that group's Launch Configuration with changes to userdata, for example.

Additionally, the -l flag is no longer necessary to invoke create on resources that are missing when updating a stack.

The above apply to LoadBalancers, FirewallRules, MsgQueues, ServerPools, and ContainerClusters.

MU::SUMMARY

I added a new MU::Logger type that will output simple strings at the very end of a deploy, for a human to read. It also includes them in the "deploy complete" email. Example:

MU.log %Q{How to interact with your Kubernetes cluster\nkubectl --kubeconfig "#{kube_conf}" get all\nkubectl --kubeconfig "#{kube_conf}" create -f some_k8s_deploy.yml}, MU::SUMMARY

...and that gives the end user a heads up on how to use Kubernetes tools with a new EKS cluster.

Slack notifications

Super easy to use. It sends "deployment complete" messages to a Slack channel, including any MU::SUMMARY messages generated during the deploy.

To enable this behavior, add a stanza in /opt/mu/etc/mu.yaml:

slack:
  webhook: https://hooks.slack.com/services/your/stuff/here
  skip_environments:
  - dev

The webhook is a Slack artifact, created like so: https://get.slack.help/hc/en-us/articles/115005265063-Incoming-WebHooks-for-Slack

The skip_environments bit is optional. You can use this to, say, only send prod deployment notifications and ignore dev.

Misc

  • Better pre-cleaning of Chef installs
  • GCP layer works better with modern configuration parsing
  • Default version for AWS ElasticSearch now 6.3
Assets 2
Loading