Instead of specifying this directly in your configuration, we’ll use the concept of k8s secrets. You decouple the k8s object from the registry configuration by just referencing the secret by it’s name. But first, let’s create a new k8s secret.
$ kubectrl create secret docker-registry <SECRET_NAME> --docker-server <REGISTRY_NAME>.azurecr.io --docker-email <YOUR_MAIL> --docker-username=<SERVICE_PRINCIPAL_ID> --docker-password <YOUR_PASSWORD>
Until recently, this site had an atom feed.
These days I spend nearly all of my time on Azure. Ansible support for Azure hasn’t been great until version 2.4, so I’ve even had to build custom modules to do some stuff internally for ourselves.
Beyond that, there’s a lot of interesting and innovative stuff happening in Azure.
In this post, I want to focus on one very specific thing – setting up Kubernetes1 on Azure. Microsoft already has some great documentation on setting up Kubernetes on Azure and there’s other documentation on the Kubernetes site itself.
I’ve done some work on getting a Kubernetes cluster up in Azure using acs-engine and this post is intended to document that.
Let’s start. I am using Debian 9 as my operating system2.
- First things first – install the dependencies
$ sudo apt-get install apt-transport-https ca-certificates curl \ gnupg2 \ software-properties-common
- Add the docker repository public key, so we can…
$ curl -fsSL https://download.docker.com/linux/$(. /etc/os-release; echo "$ID")/gpg | sudo apt-key add -
- Add the docker repository to the sources list
$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/$(. /etc/os-release; echo "$ID") \ $(lsb_release -cs) \ stable"
- Install Docker Community Edition
$ sudo apt-get install docker-ce
That should be all the required software we need to start using acs-engine.
- Next, checkout the acs-engine repo
$ git clone https://github.com/Azure/acs-engine.git
- And “bootstrap” the environment, so to speak. For the next step(s), you’ll need to run as a user who can pull docker images, which could be either root or a docker user
$ cd acs-engine $ ./scripts/devenv.sh
The last step above should take a while, as it pulls docker images and all the other dependencies required for acs-engine.
It should then drop you inside a docker container shell.
- Once you’re in the container shell, we bootstrap and build
# make bootstrap # make build
- Once complete, there should be an acs-engine binary in the bin folder.
# ./bin/acs-engine ACS-Engine deploys and manages Kubernetes, Swarm Mode, and DC/OS clusters in Azure
Usage: acs-engine [command]
Available Commands: deploy deploy an Azure Resource Manager template generate Generate an Azure Resource Manager template help Help about any command orchestrators provide info about supported orchestrators upgrade upgrades an existing Kubernetes cluster version Print the version of ACS-Engine
Flags: --debug enable verbose debug logs -h, --help help for acs-engine
Use "acs-engine [command] --help" for more information about a command.
That’s what we will use to generate templates and build our clusters using azure cli tools.
In Part II, I’ll cover the following:
- Creating a template from the examples provided in the examples folder
- Generate deployment templates using the template we create
- Create a resource group to use for the kubernetes cluster. Alternately, use an existing one.
- Validate and deploy the template
- Login and check the kubernetes cluster we just deployed
If you haven’t heard or read about 12 factor, read about it here.
The twelve-factor app is a methodology for building software-as-a-service apps that:
- Use declarative formats for setup automation, to minimize time and cost for new developers joining the project
- Have a clean contract with the underlying operating system, offering maximum portability between execution environments
- Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration
- Minimize divergence between development and production, enabling continuous deployment for maximum agility
- And can scale up without significant changes to tooling, architecture, or development practices
Listing the 12 factors here:
- One codebase tracked in revision control, many deploys
- Explicitly declare and isolate dependencies
- Store config in the environment
- Treat backing services as attached resources
- Strictly separate build and run stages
- Execute the app as one or more stateless processes
- Export services via port binding
- Scale out via the process model
- Maximize robustness with fast startup and graceful shutdown
- Keep development, staging, and production as similar as possible
- Treat logs as event streams
- Run admin/management tasks as one-off processes
what light could quench
this thirst only darkness
had eaten up with
little inkling of mercy