Creating and renewing TLS certificates is a tedious and boring task when done manually. It can be automated by using Let’s Encrypt for example but in an Enterprise environment, where you have your own CA, that’s maybe not an option any more. In this article we’ll share a workflow which leverage HashiCorp Vault to automate TLS certificate provisioning, revocation and renewal. It allows us to offer a PKI as a Service solution to our applications and users, they’ll get a self service API endpoint where they can get, renew and revoke their TLS certificates.
You may still have some bare metal servers lying around, freed by the heavy use of public clouds. But don’t throw them away yet, tooling exist to offer almost as much agility as virtual machine provisionning. Tools like Foreman, Cobbler, Razor, MAAS or OpenStack Ironic fills that gap. Today we’ll look at matchbox from CoreOS, it has a pretty name now, it used to be called coreos-baremetal and bootcfg. matchbox offers a HTTP and gRPC service which will help to easily build out CoreOS clusters out of your servers.
Evolution is drastic in IT, we now see applications running in containers, public clouds eating the world with self-service offerings. The world of computing has to adapt and provide a foundation for this constant innovation. This is exaclty what the CoreOS team have been doing for almost four years. It all started with CoreOS a minimalistic Linux operating system which have recently been renamed Container Linux, which gives a quick overview of what it is built for. It’s only purpose is to be a foundation layer to run your containerized and distributed cloud-native application. Having such a reduced footprint makes it way more secure, it was the driving force behind it. Also by reducing the adherence between your application and the infrastructure operating system, updates becomes way easier, so your environment will be kept secured. Container Linux offer a minimum set of binaries, mostly systemd, etcd, rkt and flannel for networking. Anything else can run as containers on top of Container Linux.
Containers are taking the IT world by storm, instead of re-inventing the wheel, CoreOS wants to offer the next-generation open source app container runtime, designed for security, simplicity and composability. But above all, they want to play fair with the ecosystem by ensuring it is built on common open standards and use what’s readily available like systemd and Kubernetes. rkt is written in Go, it compile to a single static binary, so it is easily portable to any modern system, for the rest read on.
As we’ve already seen in our previous articles Mirantis Cloud Platform (MCP) is really flexible and can tackle lots of different use cases. Last time we’ve looked at using Ceph as the OpenStack storage backend. Today we are reviewing different ways to leverage Neutron Open vSwitch ML2 plugin instead of the standard OpenContrail SDN solution to offer networking as a service to our users.
In the last few articles, I’ve detailed the workflow to deploy Mirantis Cloud Platform (aka MK now MCP) based on Mirantis OpenStack and a Reclass Model Driven Architecture (MDA). But you may want to use a different backend for storage then our standard MCP one, the reference Cinder LVM ISCSI Driver. In this MCP cookbook article, I’ll guide you step by step, to use Ceph as your storage backend for Glance (Images), Cinder (Volumes) and Nova (Guest Disks). You can use any of these options alone or combined.
In this article we assume that you are familiar with Salt, formulas, reclass and OpenStack-Salt. This is my cheatsheet which drives you step by step to deploy OpenStack Mitaka based on the latest model, using a new Cluster Class. If you feel lost, feel free to get back to the beginning.
After having reviewed Salt, Salt Formulas and reclass, it’s now time to put everything together to deploy OpenStack from openstack-salt project which use an elegant Model-Driven Architecture stored in a git repository which can be used for the life cycle management, auditing and documenting your infrastructure.
Now that data center are software driven, it is crucial to have a single source of truth, a kind of know all inventory about your resources, your nodes, their functions and their associated parameters, which describe everything and store it in a single location. Welcome reclass which use Class inheritance to define nodes roles and avoid duplication by gathering all important datacenter parameters in a central location. All of this will then be used by your automation tools like Salt, Ansible or Puppet to bootstrap your infrastructure as a software. In other words, reclass can be classified as a hierarchical inventory management solution. Let see how we could use it with Salt.