Those of you who have perused my blog last year (or talked to me in person) know that I’m pretty stoked about containers. I think they are very cool conceptually and can bring a lot of value to streamlining the development process.
AWS has several options for containers and I wanted to do a VERY high level run through these to distinguish them a bit and maybe whet your appetite to dive into them a little more.
If you’ve followed along in my other network posts about bridge and the rest of the default networks, you may have noticed that I keep spinning up CentOS containers. This is well and good for demos and instructional purposes but you might have also noticed that they don’t really do anything. I mean they exist, but that isn’t why you run things in your environment. You don’t have a bunch of server OSes spun up doing nothing, right? RIGHT?
Well, we hope not anyway. Ideally your server actually does something like hosts an app, database, or webserver. In this post we are going to explore some aspects of bridge networking and get a little more into the underpinnings of Docker. And in order do that, hey we need a container that actually does something! Continue reading
As with our previous post on bridge, the intent here is to explore the remaining standard (mostly non-swarm) network configurations. Those configurations are host, none, and the newer MACVLAN.
Unlike bridge these are non-default configurations which means you must manually specify the network somewhere. In our case we are just going to explicitly list the network when we run the container. We will also explore the configuration elements that we looked at earlier. Continue reading
If you have been under a rock (like I was for a while!), Docker is a container technology and containers are very cool. Containers sparked my interest in the same way that virtualization did the first time I saw it. I really regret not getting into it sooner but better late than never. Seriously if you haven’t played with containers at all try it on a local system, VM, or use this really nifty site http://training.play-with-docker.com/
vRealize Automation 7.3 was just released and there is a lot to unpack. I haven’t had the chance yet to play with the new version (hope to soon!), but I wanted to take a brief moment to call out some cool things I noticed. Here are the release notes (link) if you want to check the whole thing out.
If you’ve been following along, whew! Last post in this series and likely the easiest. Let’s do a quick recap.
In our first post we basically went through the process of determining “how do I do what I want to do?” In our case that was making a REST call to UCSD and kicking off a workflow. We used the Postman utility to help accomplish this.
In the second post we went through the process of “how do I get vRealize Orchestrator to do what I want to do?” Here we used some existing sample workflows and made some modifications to do what we wanted, how we wanted.
In this final post we need to expose that workflow to vRealize Automation so that it can be consumed in a catalog.
OK this is definitely the meatiest part of this series, but bear with me and we’ll get through it. Before we get started, it is important to note there are a million different ways to skin this cat in vRO. This is just one that I find to be fairly straightforward.
I will also fully disclose that this is not easy and at times very frustrating. Some of the vRO stuff is well documented, but some of it is behind curtains and seems to be (on some level or another) different than some of the provided API documentation. I say that just to say, if you are getting your angryface on while working through some of this, you are not alone. Hopefully this series will help alleviate some of that frustration! Continue reading