In this post I will now show you the steps involved in creating a Docker Swarm configuration using docker-machine with Photon Controller driver plugin. In previous posts, I showed how you can setup Photon OS to deploy Photon Controller and I also showed you how to build docker-machine for Photon Controller. Note that there are a lot of ways to deploy Swarm. Since I was given a demonstration on doing this using “Consul” for cluster membership and discovery, that is the mechanism that I am going to use here. Now, a couple of weeks back, we looked at deploying Docker Swarm using the “cluster” mechanism also available in Photon Controller. This mechanism used “etcd” for discovery, configuration, and so on. In this example, we are going to deploy Docker Swarm from the ground up, step-by-step, using the docker-machine with photon controller driver, but in this example we are going to use “Consul” which does something very similar to “etcd”.
As many regular reader will be aware, I’ve been spending a lot of time recently on VMware’s Cloud Native App solutions. This is due to an internal program available to VMware employees called a Take-3. A Take-3 is where employees can take 3 months out of their current role and try a new challenge in another part of the company. Once we launched VSAN 6.2 earlier this year, I thought this would be an opportune time to try something different. Thanks to the support from the management teams in both my Storage and Availability BU (SABU) and the Cloud Native Apps BU (CNABU), I started my Take-3 at the beginning of May. This is when my CNA articles on VIC (vSphere Integrated Containers) and Photon Controller first started to appear. Only recently I was asked an interesting question – when would I use VIC and when would I use Photon Controller? That is a good question, as both products enable customer to use containers on VMware products and solutions. So let me see if I can provide some guidance, as I asked the same question from some of the guiding lights in the CNABU.
I’m thrilled to have had a session accepted at this year’s VMworld. I’m also going to be a co-speaker on another session. As you might have guessed, both presentations are on Virtual SAN (VSAN), and I am co-presenting both sessions with my buddy Paudie O’Riordan.
In the first session, we will be talking about how to conduct a successful proof of concept (PoC) on VSAN, which will cover how to prepare, how to test, and what gotchas you need to be aware of when going through a PoC with VSAN. This is session id STO7535 and it is currently scheduled for Wednesday morning (31st August) at 08:30am.
In the other session, which covers day #2 operations, we will cover items like upgrades, troubleshooting, remediation, and monitoring of VSAN, and all those other things that you need to care about when you have VSAN in production. This is session id STO7534 and is scheduled for Tuesday morning (30th August) at 11:00am.
If you have any thoughts on what you would like to see covered during the session, please leave a comment. We’re still putting together the content, and we are wide open to suggestions.
Hope to see you at one of the sessions.
I’m delighted to announce the availability of a joint Rubrik and VMware Virtual SAN (VSAN) white paper. Both Rubrik and Virtual SAN epitomize many of the features and characteristics of Software Defined Storage, in particular simplifying storage and backup/restore for vSphere Administrators. Other features include abstracting the underlying storage into one large pool, and consuming/utilizing that underlying storage through policies, whether these are for virtual machine deployment or backup. If you are completely new to VSAN and/or Rubrik, this paper gives a good explanation of both technologies. The paper also explains how Rubrik and VSAN work seamlessly together to back up and restore virtual machines deployed on VSAN.
I should also mention that my co-author was none other than the one and only Chris Wahl, and as always, it was a pleasure to work with him on this paper.
I’d like to thank Chris, Julia and Sara of Rubrik for their attention to detail on this paper. I think it has turned out extremely well, and we hope you get a lot of good information from it.
In previous posts we have looked at using a “cluster” for deploying docker swarm on top of photon controller. Of course, deploying docker swarm via the cluster management construct may not be what some customers wish to do, so now we have full support for “docker-machine” on photon controller as well. This will allow you to create your own docker swarm clusters using instructions provided by Docker. In this post, we will look at getting you started with building the docker-machine driver plugin, setting up Photon Controller, and then the setup needed to allow the deploying of docker-machine on Photon Controller.
You can find the software and additional information on github.
VMware has just officially announced Photon OS 1.0. This follows on from the RC (Release Candidate) announcement back in late April. For those of you who are not familiar with Photon OS, this is a minimal Linux container host (in the form of a Virtual Machine), optimized to run on VMware products such as ESXi. It can run containers which adhere to Docker, rkt, and the Pivotal Garden container specifications.
In some earlier post, I provided instructions on how one could deploy Kubernetes (K8S) on Photon Controller using the built-in photon controller CLI. In this next post, I want to show you how Kubernetes can be deployed natively, using kube-up and kube-down, on Photon Controller v0.9.
In this example I am using Photon OS, a minimal Linux container host, optimized to run on vSphere (and other VMware products). Now in order to deploy K8S, a number of additional tooling needs to be added to Photon OS. The requirements are highlighted in this earlier blog post. Once all the necessary components are in place, we are ready to deploy Kubernetes.
*** Please note that at the time of writing, Photon Controller is still not GA ***