Series on The IT Hollow

Connecting to a Supervisor Namespace

Mon, 24 Aug 2020 14:15:00 +0000

In this post we’ll finally connect to our Supervisor Cluster Namespace through the Kubernetes cli and run some commands for the first time.

In the last post we created a namespace within the Supervisor Cluster and assigned some resource allocations and permissions for our example development user. Now it’s time to access that namespace so that real work can be done using the platform.

First, login to vCenter again with the administrator@vsphere.local account and navigate to the namespace that was previously created. You should see a similar screen where we configured our permissions. In the Status tile, click one of the links to either open in a browser or copy the URL to then open in a browser.

Creating Supervisor Namespaces

Mon, 17 Aug 2020 14:15:00 +0000

Congratulations, you’ve deployed the Workload Management components for your vSphere 7 cluster. If you’ve been following along with the series so far, you’ll have left off with a workload management cluster created and ready to being configuring your cluster for use with Kubernetes.

The next step in the process is to create a namespace. Before we do that, it’s probably useful to recap what a namespace is used for.

Namespaces the Theory

Depending on your past experiences, a namespace will likely seem familiar to you in some fashion. If you have a kubernetes background, you’ll be familiar with namespaces as a way to set permissions for a group of users (or a project, etc) and for assigning resources. Alternatively, if you have a vSphere background, you’re used to using things like Resource Pools to set resource allocation.

vSphere 7 with Tanzu - Getting Started Guide

Tue, 14 Jul 2020 14:16:18 +0000

VMware released the new version of vSphere with functionality to build and manage Kubernetes clusters. This series details how to deploy, configure, and use a lab running vSphere 7 with Kubernetes enabled.

The instructions within this post are broken out into sections. vSphere 7 requires pre-requisites at the vSphere level as well as a full NSX-T deployment. Follow these steps in order to build your own vSphere 7 with Kubernetes lab and start using Kubernetes built right into vSphere.

Kubernetes Validating Admission Controllers

Tue, 26 May 2020 15:05:00 +0000

Hey! Who deployed this container in our shared Kubernetes cluster without putting resource limits on it? Why don’t we have any labels on these containers so we can report for charge back purposes? Who allowed this image to be used in our production cluster?

If any of the questions above sound familiar, its probably time to learn about Validating Admission Controllers.

Validating Admission Controllers - The Theory

Admission Controllers are used as a roadblocks before objects are deployed to a Kubernetes cluster. The examples from the section above are common rules that companies might want to enforce before objects get pushed into a production Kubernetes cluster. These admission controllers can be from custom code that you’ve written yourself, or a third party admission controller. A common open-source project that manages admission control rules is Open Policy Agent (OPA).

Kubernetes Liveness and Readiness Probes

Mon, 18 May 2020 14:00:00 +0000

Just because a container is in a running state, does not mean that the process running within that container is functional. We can use Kubernetes Readiness and Liveness probes to determine whether an application is ready to receive traffic or not.

Liveness and Readiness Probes - The Theory

On each node of a Kubernetes cluster there is a Kubelet running which manages the pods on that particular node. Its responsible for getting images pulled down to the node, reporting the node’s health, and restarting failed containers. But how does the Kubelet know if there is a failed container?

Kubernetes Pod Auto-scaling

Mon, 04 May 2020 14:05:00 +0000

You’ve built your Kubernetes cluster(s). You’ve built your apps in containers. You’ve architected your services so that losing a single instance doesn’t cause an outage. And you’re ready for cloud scale. You deploy your application and are waiting to sit back and “profit.”

When your application spins up and starts taking on load, you are able to change the number of replicas to handle the additional load, but what about the promises of cloud and scaling? Wouldn’t it be better to deploy the application and let the platform scale the application automatically?

Kubernetes Resource Requests and Limits

Mon, 20 Apr 2020 15:00:00 +0000

Containerizing applications and running them on Kubernetes doesn’t mean we can forget all about resource utilization. Our thought process may have changed because we can much more easily scale-out our application as demand increases, but many times we need to consider how our containers might fight with each other for resources. Resource Requests and Limits can be used to help stop the “noisy neighbor” problem in a Kubernetes Cluster.

Resource Requests and Limits - The Theory

Kubernetes uses the concept of a “Resource Request” and a “Resource Limit” when defining how many resources a container within a pod should receive. Lets look at each of these topics on their own, starting with resource requests.

Deploy Kubernetes on AWS

Mon, 13 Jan 2020 15:15:39 +0000

The way you deploy Kubernetes (k8s) on AWS will be similar to how it was done in a previous post on vSphere. You still setup nodes, you still deploy kubeadm, and kubectl but there are a few differences when you change your cloud provider. For instance on AWS we can use the LoadBalancer resource against the k8s API and have AWS provision an elastic load balancer for us. These features take a few extra tweaks in AWS.

Deploy Kubernetes on vSphere

Wed, 08 Jan 2020 15:00:04 +0000

If you’re struggling to deploy Kubernetes (k8s) clusters, you’re not alone. There are a bunch of different ways to deploy Kubernetes and there are different settings depending on what cloud provider you’re using. This post will focus on installing Kubernetes on vSphere with Kubeadm. At the end of this post, you should have what you need to manually deploy k8s in a vSphere environment on ubuntu.

Prerequisites

NOTE: This tutorial uses the “in-tree” cloud provider for vSphere. This is not the preferred method for deployment going forward. More details can be found here for reference.

Kubernetes - Jobs and CronJobs

Mon, 16 Dec 2019 15:05:36 +0000

Sometimes we need to run a container to do a specific task, and when its completed, we want it to quit. Many containers are deployed and continuously run, such as a web server. But other times we want to accomplish a single task and then quit. This is where a Job is a good choice.

Jobs and CronJobs - The Theory

Perhaps, we need to run a batch process on demand. Maybe we built an automation routine for something and want to kick it off through the use of a container. We can do this by submitting a job to the Kubernetes API. Kubernetes will run the job to completion and then quit.

Kubernetes - Pod Security Policies

Tue, 19 Nov 2019 15:05:04 +0000

Securing and hardening our Kubernetes clusters is a must do activity. We need to remember that containers are still just processes running on the host machines. Sometimes these processes can get more privileges on the Kubernetes node than they should, if you don’t properly setup some pod security. This post explains how this could be done for your own clusters.

Pod Security Policies - The Theory

Pod Security policies are designed to limit what can be run on a Kubernetes cluster. Typical things that you might want to limit are: pods that have privileged access, pods with access to the host network, and pods that have access to the host processes just to name a few. Remember that a container isn’t as isolated as a VM so we should take care to ensure our containers aren’t adversely affecting our nodes’s health and security.

Kubernetes - Network Policies

Mon, 21 Oct 2019 14:05:08 +0000

In the traditional server world, we’ve taken great lengths to ensure that we can micro-segment our servers instead of relying on a few select firewalls at strategically defined chokepoints. What do we do in the container world though? This is where network policies come into play.

Network Policies - The Theory

In a default deployment of a Kubernetes cluster, all of the pods deployed on the nodes can communicate with each other. Some security folks might not like to hear that, but never fear, we have ways to limit the communications between pods and they’re called network policies.

Kubernetes - Desired State and Control Loops

Mon, 16 Sep 2019 14:05:30 +0000

If you’ve just gotten started with Kubernetes, you might be curious to know how the desired state is achieved? Think about it, you pass a YAML file to the API server and magically stuff happens. Not only that, but when disaster strikes (e.g. pod crashes) Kubernetes also makes it right again so that it matches the desired state.

The mechanism that allows for Kubernetes to enforce this desired state is the control loop. The basics of this are pretty simple. A control loop can be though of in three stages.

Kubernetes - DaemonSets

Tue, 13 Aug 2019 14:10:04 +0000

DaemonSets can be a really useful tool for managing the health and operation of the pods within a Kubernetes cluster. In this post we’ll explore a use case for a DaemonSet, why we need them, and an example in the lab.

DaemonSets - The Theory

DaemonSets are actually pretty easy to explain. A DaemonSet is a Kubernetes construct that ensures a pod is running on every node (where eligible) in a cluster. This means that if we were to create a DaemonSet on our six node cluster (3 master, 3 workers), the DaemonSet would schedule the defined pods on each of the nodes for a total of six pods. Now, this assumes there are either no taints on the nodes, or there are tolerations on the DaemonSets.

Kubernetes - Taints and Tolerations

Mon, 29 Jul 2019 14:15:22 +0000

One of the best things about Kubernetes, is that I don’t have to think about which piece of hardware my container will run on when I deploy it. The Kubernetes scheduler can make that decision for me. This is great until I actually DO care about what node my container runs on. This post will examine one solution to pod placement, through taints and tolerations.

Taints - The Theory

Suppose we had a Kubernetes cluster where we didn’t want any pods to run on a specific node. You might need to do this for a variety of reasons, such as:

Kubernetes - Helm

Mon, 10 Jun 2019 14:02:52 +0000

The Kubernetes series has now ventured into some non-native k8s discussions. Helm is a relatively common tool used in the industry and it makes sense to talk about why that is. This post covers the basics of Helm so we can make our own evaluations about its use in our Kubernetes environment.

Helm - The Theory

So what is Helm? In the most simplest terms its a package manager for Kubernetes.
Think of Helm this way, Helm is to Kubernetes as yum/apt is to Linux. Yeah, sounds pretty neat now doesn’t it?

Kubernetes - Pod Backups

Mon, 03 Jun 2019 14:00:58 +0000

The focus of this post is on pod based backups, but this could also go for Deployments, replica sets, etc. This is not a post about how to backup your Kubernetes cluster including things like etcd, but rather the resources that have been deployed on the cluster. Pods have been used as an example to walk through how we can take backups of our applications once deployed in a Kubernetes cluster.

Kubernetes - Role Based Access

Mon, 20 May 2019 14:10:48 +0000

As with all systems, we need to be able to secure a Kubernetes cluster so that everyone doesn’t have administrator privileges on it. I know this is a serious drag because no one wants to deal with a permission denied error when we try to get some work done, but permissions are important to ensure the safety of the system. Especially when you have multiple groups accessing the same resources. We might need a way to keep those groups from stepping on each other’s work, and we can do that through role based access controls.

Kubernetes - StatefulSets

Mon, 01 Apr 2019 14:20:48 +0000

We love deployments and replica sets because they make sure that our containers are always in our desired state. If a container fails for some reason, a new one is created to replace it. But what do we do when the deployment order of our containers matters? For that, we look for help from Kubernetes StatefulSets.

StatefulSets - The Theory

StatefulSets work much like a Deployment does. They contain identical container specs but they ensure an order for the deployment. Instead of all the pods being deployed at the same time, StatefulSets deploy the containers in sequential order where the first pod is deployed and ready before the next pod starts. (NOTE: it is possible to deploy pods in parallel if you need them to, but this might confuse your understanding of StatefulSets for now, so ignore that.) Each of these pods has its own identity and is named with a unique ID so that it can be referenced.

Kubernetes - Cloud Providers and Storage Classes

Wed, 13 Mar 2019 14:20:23 +0000

In the previous post we covered Persistent Volumes (PV) and how we can use those volumes to store data that shouldn’t be deleted if a container is removed. The big problem with that post is that we have to manually create the volumes and persistent volume claims. It would sure be nice to have those volumes spun up automatically wouldn’t it? Well, we can do that with a storage class. For a storage class to be really useful, we’ll have to tie our Kubernetes cluster in with our infrastructure provider like AWS, Azure or vSphere for example. This coordination is done through a cloud provider.

Kubernetes - Persistent Volumes

Mon, 04 Mar 2019 15:00:51 +0000

Containers are often times short lived. They might scale based on need, and will redeploy when issues occur. This functionality is welcomed, but sometimes we have state to worry about and state is not meant to be short lived. Kubernetes persistent volumes can help to resolve this discrepancy.

Volumes - The Theory

In the Kubernetes world, persistent storage is broken down into two kinds of objects. A Persistent Volume (PV) and a Persistent Volume Claim (PVC). First, lets tackle a Persistent Volume.

Kubernetes - Secrets

Mon, 25 Feb 2019 15:00:56 +0000

Secret, Secret, I’ve got a secret! OK, enough of the Styx lyrics, this is serious business. In the previous post we used ConfigMaps to store a database connection string. That is probably not the best idea for something with a sensitive password in it. Luckily Kubernetes provides a way to store sensitive configuration items and its called a “secret”.

Secrets - The Theory

The short answer to understanding secrets would be to think of a ConfigMap, which we have discussed in a previous post in this series, but with non-clear text.

Kubernetes - ConfigMaps

Wed, 20 Feb 2019 15:00:40 +0000

Sometimes you need to add additional configurations to your running containers. Kubernetes has an object to help with this and this post will cover those ConfigMaps.

ConfigMaps - The Theory

Not all of our applications can be as simple as the basic nginx containers we’ve deployed earlier in this series. In some cases, we need to pass configuration files, variables, or other information to our apps.

The theory for this post is pretty simple, ConfigMaps store key/value pair information in an object that can be retrieved by your containers. This configuration data can make your applications more portable.

Kubernetes - DNS

Mon, 18 Feb 2019 15:00:16 +0000

DNS is a critical service in any system. Kubernetes is no different, but Kubernetes will implement its own domain naming system that’s implemented within your Kubernetes cluster. This post explores the details that you need to know to operate a k8s cluster properly.

Kubernetes DNS - The theory

I don’t want to dive into DNS too much since it’s a core service most should be familiar with. But at a really high level, DNS translates an IP address that might be changing, with an easily remember-able name such as “theithollow.com”. Every network has a DNS server, but Kubernetes implements their own DNS within the cluster to make connecting to containers a simple task.

Kubernetes - Ingress

Wed, 13 Feb 2019 15:00:46 +0000

It’s time to look closer at how we access our containers from outside the Kubernetes cluster. We’ve talked about Services with NodePorts, LoadBalancers, etc., but a better way to handle ingress might be to use an ingress-controller to proxy our requests to the right backend service. This post will take us through how to integrate an ingress-controller into our Kubernetes cluster.

Ingress Controllers - The Theory

Lets first talk about why we’d want to use an ingress controller in the first place. Take an example web application like you might have for a retail store. That web application might have an index page at “http://store-name.com/" and a shopping cart page at “http://store-name.com/cart" and an api URI at “http://store-name.com/api". We could build all these in a single container, but perhaps each of those becomes their own set of pods so that they can all scale out independently. If the API needs more resources, we can just increase the number of pods and nodes for the api service and leave the / and the /cart services alone. It also allows for multiple groups to work on different parts simultaneously but we’re starting to drift off the point which hopefully you get now.

Kubernetes - KUBECONFIG and Context

Mon, 11 Feb 2019 15:00:26 +0000

You’ve been working with Kubernetes for a while now and no doubt you have lots of clusters and namespaces to deal with now. This might be a good time to introduce Kubernetes KUBECONFIG files and context so you can more easily use all of these different resources.

KUBECONFIG and Context - The Theory

When you first setup your Kubernetes cluster you created a config file likely stored in your $HOME/.kube directory. This is the KUBECONFIG file and it is used to store information about your connection to the Kubernetes cluster. When you use kubectl to execute commands, it gets the correct communication information from this KUBECONFIG file. This is why you would’ve needed to add this file to your $PATH variable so that it could be used correctly by the kubectl commands.

Kubernetes - Namespaces

Wed, 06 Feb 2019 15:00:13 +0000

In this post we’ll start exploring ways that you might be able to better manage your Kubernetes cluster for security or organizational purposes. Namespaces become a big piece of how your Kubernetes cluster operates and who sees what inside your cluster.

Namespaces - The Theory

The easiest way to think of a namespace is that its a logical separation of your Kubernetes Cluster. Just like you might have segmented a physical server into several virtual severs, we can segment our Kubernetes cluster into namespaces. Namespaces are used to isolate resources within the control plane. For example if we were to deploy a pod in two different namespaces, an administrator running the “get pods” command may only see the pods in one of the namespaces. The pods could communicate with each other across namespaces however.

Kubernetes - Service Publishing

Tue, 05 Feb 2019 16:30:54 +0000

A critical part of deploying containers within a Kubernetes cluster is understanding how they use the network. In previous posts we’ve deployed pods and services and were able to access them from a client such as a laptop, but how did that work exactly? I mean, we had a bunch of ports configured in our manifest files, so what do they mean? And what do we do if we have more than one pod that wants to use the same port like 443 for https?

Kubernetes - Endpoints

Mon, 04 Feb 2019 15:00:02 +0000

It’s quite possible that you could have a Kubernetes cluster but never have to know what an endpoint is or does, even though you’re using them behind the scenes. Just in case you need to use one though, or if you need to do some troubleshooting, we’ll cover the basics of Kubernetes endpoints in this post.

Endpoints - The Theory

During the post where we first learned about Kubernetes Services, we saw that we could use labels to match a frontend service with a backend pod automatically by using a selector. If any new pods had a specific label, the service would know how to send traffic to it. Well the way that the service knows to do this is by adding this mapping to an endpoint. Endpoints track the IP Addresses of the objects the service send traffic to. When a service selector matches a pod label, that IP Address is added to your endpoints and if this is all you’re doing, you don’t really need to know much about endpoints. However, you can have Services where the endpoint is a server outside of your cluster or in a different namespace (which we haven’t covered yet).

Kubernetes - Services and Labels

Thu, 31 Jan 2019 15:00:54 +0000

If you’ve been following the series, you may be thinking that we’ve built ourselves a problem. You’ll recall that we’ve now learned about Deployments so that we can roll out new pods when we do upgrades, and replica sets can spin up new pods when one dies. Sounds great, but remember that each of those containers has a different IP address. Now, I know we haven’t accessed any of those pods yet, but you can imagine that it would be a real pain to have to go lookup an IP Address every time a pod was replaced, wouldn’t it? This post covers Kubernetes Services and how they are used to address this problem, and at the end of this post, we’ll access one of our pods … finally.

Kubernetes - Deployments

Wed, 30 Jan 2019 15:01:37 +0000

After following the previous posts, we should feel pretty good about deploying our pods and ensuring they are highly available. We’ve learned about naked pods and then replica sets to make those pods more HA, but what about when we need to create a new version of our pods? We don’t want to have an outage when our pods are replaced with a new version do we? This is where “Deployments” comes into play.

Kubernetes - Replica Sets

Mon, 28 Jan 2019 15:00:59 +0000

In a previous post we covered the use of pods and deployed some “naked pods” in our Kubernetes cluster. In this post we’ll expand our use of pods with Replica Sets.

Replica Sets - The Theory

One of the biggest reasons that we don’t deploy naked pods in production is that they are not trustworthy. By this I mean that we can’t count on them to always be running. Kubernetes doesn’t ensure that a pod will continue running if it crashes. A pod could die for all kinds of reasons such as a node that it was running on had failed, it ran out of resources, it was stopped for some reason, etc. If the pod dies, it stays dead until someone fixes it which is not ideal, but with containers we should expect them to be short lived anyway, so let’s plan for it.

Getting Started with Kubernetes

Sat, 26 Jan 2019 22:38:39 +0000

The following posts are meant to get a beginner started with the process of understanding Kubernetes. They include basic level information to start understanding the concepts of the Kubernetes service and include both theory and examples.

To follow along with the series, a Kubernetes cluster should be deployed and admin permissions are needed to perform many of the steps. If you wish to follow along with each of the posts, a cluster with cloud provider integration may be needed. In some cases we need a Load Balancer and elastic storage options.

Kubernetes - Pods

Mon, 21 Jan 2019 16:30:30 +0000

We’ve got a Kubernetes cluster setup and we’re ready to start deploying some applications. Before we can deploy any of our containers in a kubernetes environment, we’ll need to understand a little bit about pods.

Pods - The Theory

In a docker environment, the smallest unit you’d deal with is a container. In the Kubernetes world, you’ll work with a pod and a pod consists of one or more containers. You cannot deploy a bare container in Kubernetes without it being deployed within a pod.

Upgrade to vRA 7.5

Mon, 08 Oct 2018 14:03:53 +0000

Upgrading your vRealize Automation instance has some times been a painful exercise. But this was in the early days after VMware purchased the product from DynamicOps. It’s taken a while, but the upgrade process has improved for each and every version, in my opinion, and 7.5 is no exception. If you’re on a previous version, here is a quick rundown on the upgrade process from 7.4 to 7.5.

Note: As always, please read the the official upgrade documentation. It includes prerequisites and steps that should always be followed. https://docs.vmware.com/en/vRealize-Automation/7.5/vrealize-automation-7172732to75upgrading.pdf

AWS Session Manager

Mon, 01 Oct 2018 14:05:01 +0000

Amazon has released yet another Simple Systems Manager service to improve the management of EC2 instances. This time, it’s AWS Session Manager. Session Manager is a nifty little service that lets you assign permissions to users to access an instances’s shell. Now, you might be thinking, “Why would I need this? I can already add SSH keys to my instances at boot time to access my instances.” You’d be right of course, but think of how you might use Session Manager. Instead of having to deal with adding SSH keys, and managing access/distribution of the private keys, we can manage access through AWS Identity and Access Management permissions.

AWS IAM Indecision

Mon, 07 May 2018 14:55:55 +0000

Identity and Access Management (IAM) can be a confusing topic for people that are new to Amazon Web Services. There are IAM Users that could be used for authentication or solutions considered part of the AWS Directory Services such as Microsoft AD, Simple AD, or AD Connector. If none of these sound appealing, there is always the option to use Federation with a SAML 2.0 solution like OKTA, PING, or Active Directory Federation Services (ADFS). If all of these option have given you a case of decision fatigue, then hopefully this post and the associate links will help you to decide how your environment should be setup.

Manage Multiple AWS Accounts with Role Switching

Mon, 30 Apr 2018 14:05:52 +0000

A pretty common question that comes up is how to manage multiple accounts within AWS from a user perspective. Multi-Account setups are common to provide control plane separation between Production, Development, Billing and Shared Services accounts but do you need to setup Federation with each of these accounts or create an IAM user in each one? That makes those accounts kind of cumbersome to manage and the more users we have the more chance one of them could get hacked.

AWS Directory Service - AD Connector

Mon, 23 Apr 2018 14:05:05 +0000

Just because you’ve started moving workloads into the cloud, doesn’t mean you can forget about Microsoft Active Directory. Many customers simply stand up their own domain controllers on EC2 instances to provide domain services. But if you’re moving to AWS there are also some great services you can take advantage of, to provide similar functionality. This post focuses on AD Connector which makes a connection to your on-premises or EC2 installed domain controllers. AD Connector doesn’t run your Active Directory but rather uses your existing active directory intances within AWS. As such, in order to use AD Connector you would need to have a VPN connection or Direct Connect to provide connectivity back to your data center. Also, you’ll need to be prepared to have credentials to connect to the domain. Domain Admin credentials will work, but as usual you should use as few privileges as possible so delegate access to a user with the follow permissions:

Manage vSphere Virtual Machines through AWS SSM

Mon, 06 Nov 2017 15:15:18 +0000

Amazon Web Services has some great tools to help you operate your EC2 instances with their Simple Systems Manager services. These services include ensuring patches are deployed within maintenance windows specified by you, automation routines that are used to ensure state and run commands on a fleet of servers through the AWS console. These tools are great but wouldn’t be be even better if I could use these tools to manage my VMware virtual machines too? Well, you’re in luck, because EC2 SSM can do just that and better yet, the service itself is free! Now, if you’ve followed along with the " AWS EC2 Simple Systems Manager Reference" guide you’ve probably already seen the goodies that we’ve got available, so this post is used to show you how you can use these same tools on your vSphere, Hyper-V or other on-premises platforms.

AWS EC2 Simple Systems Manager Reference

Mon, 02 Oct 2017 14:07:07 +0000

Please use this post as a landing page to get you started with using the EC2 Simple Systems Manager services from Amazon Web Services. Simple Systems Manager or (SSM) is a set of services used to manage EC2 instances as well as on-premises machines (known as managed instances) with the SSM agent installed on them. You can use these services to maintain state, run ad-hoc commands, and configure patch compliance among other things.

AWS EC2 Systems Manager - State Manager

Tue, 26 Sep 2017 14:06:57 +0000

Sometimes you need to ensure that things are always a certain way when you deploy AWS EC2 instances. This could be things like making sure your servers are always joined to a domain when being deployed, or making sure you run an Ansible playbook every hour. The point of the AWS EC2 SSM State Manager service is to define a consistent state for your EC2 instances.

This post will use a fictional use case where I have a an EC2 instance or instances that are checking every thirty minutes to see if they should use a new image for their Apache website. The instance will check against the EC2 Simple Systems Manager Parameter Store, which we’ve discussed in a previous post, and will download the image from the S3 location retrieved from that parameter.

AWS EC2 Simple Systems Manager Documents

Mon, 18 Sep 2017 14:32:16 +0000

Amazon Web Services uses Systems Manager Documents to define actions that should be taken on your instances. This could be a wide variety of actions including updating the operating system, copying files such as logs to another destination or re-configuring your applications. These documents are written in Javascript Object Notation (JSON) and are stored within AWS for use with theother Simple Systems Manager (SSM) services such as the Automation Service or Run command.

EC2 Systems Manager Parameter Store

Mon, 11 Sep 2017 14:15:52 +0000

Generally speaking, when you deploy infrastructure through code, or run deployment scripts you’ll need to have a certain amount of configuration data. Much of your code will have install routines but what about the configuration information that is specific to your environment? Things such as license keys, service accounts, passwords, or connection strings are commonly needed when connecting multiple services together. So how do you code that exactly? Do you pass the strings in at runtime as a parameter and then hope to remember those each time you execute code? Do you bake those strings into the code and then realize that you’ve got sensitive information stored in your deployment scripts?

Adding an Azure Endpoint to vRealize Automation 7

Mon, 20 Mar 2017 14:03:55 +0000

As of vRealize Automation 7.2, you can now deploy workloads to Microsoft Azure through vRA’s native capabilities. Don’t get too excited here though since the process for adding an endpoint is much different than it is for other endpoints such as vSphere or AWS. The process for Azure in vRA 7 is to leverage objects in vRealize Orchestrator to do the heavy lifting. If you know things like resource mappings and vRO objects, you can do very similar tasks in the tool.

Getting Started with vRealize Automation Course

Mon, 28 Nov 2016 15:09:05 +0000

If you’re trying to get started with vRealize Automation and don’t know where to get started, you’re in luck. Pluralsight has just released my course on “Getting Started with vRealize Automation 7”, which will give you a great leg up on your new skills. In this course you’ll learn to install the solution, configure the basics, connect it to your vSphere environment and publish your first blueprints. The course will explain why you’d want to go down the path of using vRA 7 in the first place and how to use the solution.

UCS Director Infrastructure Setup

Wed, 12 Oct 2016 14:00:05 +0000

UCS Director is a cloud management platform and thus requires some infrastructure to deploy the orchestrated workloads. In many cases UCS Director can also orchestrate the configuration and deployment of bare metal or hardware as well, such as configuring new VLANs on switches, deploying operating systems on blades and setting hardware profiles etc. This post focuses on getting those devices to show up in UCS Director so that additional automation can be performed.

Scaling in vRealize Automation

Thu, 06 Oct 2016 14:18:06 +0000

One of the new features of vRealize Automation in version 7.1 is the ability to scale out or scale in your servers. This sort of scaling is a horizontal scaling of the number of servers. For instance, if you had deployed a single web server, you can scale out to two, three etc. When you scale in, you can go from four servers to three and so on.

Use Cases

The use cases here could really vary widely. The easiest to get started with would be some sort of a web / database deployment where the web servers have some static front end web pages and can be deployed over and over again with the same configurations. If we were to place the web servers behind a load balancer (yep, think NSX here for you vSphere junkies) then your web applications can be scaled horizontally based on when you run out of resources.

Add Custom Items to vRealize Automation

Tue, 05 Jul 2016 14:14:41 +0000

vRealize Automation lets us publish vRealize Orchestrator workflows to the service catalog, but to get more functionality out of these XaaS blueprints, we can add the provisioned resources to the items list. This allows us to manage the lifecycle of these items and even perform secondary “Day 2 Operations” on these items later.

For the example in this post, we’ll be provisioning an AWS Security group in an existing VPC. For now, just remember that AWS Security groups are not managed by vRA, but with some custom work, this is all about to change.

vRealize Code Stream with Artifactory

Mon, 23 May 2016 14:04:37 +0000

vRealize Code Stream now comes pre-packaged with JFrog Artifactory which allows us to do some cool things while we’re testing and deploying new code. To begin this post, lets take a look at what an artifactory is and how we can use it.

An artifactory is a version control repository, typically used for binary objects like .jar files. You might already be thinking, how is this different from GIT? My Github account already has repos and does its own version control. True, but what if we don’t want to pull down an entire repo to do work? Maybe we only need a single file of a build or we want to be able to pull down different versions of the same file without creating branches, forks, additional repos or committing new code? This is where an artifactory service can really shine.

Software Defined Networking with vRealize Automation and NSX

Mon, 12 Oct 2015 14:30:53 +0000

This is a series of posts helping you get familiarized with how VMware’s vRealize Automation 6 can leverage VMware’s NSX product to provide software defined networking. The series will show you how to do some basic setup of NSX as well as how to use Private, Routed and NAT networks all from within vRA.

vRealize Automation 6 with NSX - NSX Setup

vRealize Automation 6 with NSX - Private Networks

vRealize Automation 6 with NSX - Routed Networks

vRealize Automation 6 with NSX - NAT

vRealize Automation 6 with NSX - Load Balancing

vRealize Automation 6 with NSX - Firewall

vRealize Automation 6 with NSX - Initial Setup of NSX

Mon, 12 Oct 2015 14:00:22 +0000

Before we can start deploying environments with automated network segments, we need to do some basic setup of the NSX environment.

NSX Manager Setup

It should be obvious that you need to setup NSX Manager, deploy controllers and do some host preparation. These are basic setup procedures just to use NSX even without vRealize Automation in the middle of things, but just as a quick review:

Install NSX Manager and deploy NSX Controller Nodes

NSX Manager setup can be deployed from an OVA and then you must register the NSX Manager with vCenter. After this is complete, deploy three NSX Controller nodes to configure your logical constructs.

Assign a VM to a Rubrik slaDomain

Mon, 14 Sep 2015 14:00:16 +0000

This last post in the series shows you how Nick Colyer and I to tie everything together. If you want to just download the plugins and get started, please visit Github.com and import the plugins into your own vRealize Orchestrator environment.

Download the Plugin from Github

NOTE: The first version of this code has been refactored and migrated to Github in Rubrik’s Repository since the time of this initial writing

To recap where we’ve been, we:

Get Rubrik VM through vRealize Orchestrator

Thu, 10 Sep 2015 14:07:51 +0000

Part four of this series will show you how to lookup a VM in the Rubrik Hybrid Cloud appliance through the REST API by using vRealize Orchestrator. If you’d rather just download the plugin and get using it, check out the link to Github to get the plugin and don’t forget to check out Nick Colyer’s post over at systemsgame.com about how to use it.

Download the Plugin from Github

NOTE: The first version of this code has been refactored and migrated to Github in Rubrik’s Repository since the time of this initial writing

Rubrik API Logins through vRealize Orchestrator

Tue, 08 Sep 2015 14:00:17 +0000

Part three of this series focuses on how Nick Colyer and I built the authentication piece of the plugin so that we could then pass commands to the Rubrik appliance. An API requires a login just like any other portal would. Since this is a a REST API, we actually need to do a “POST” on the login resource to get ourselves an authentication token.

Download the Plugin from Github

NOTE: The first version of this code has been refactored and migrated to Github in Rubrik’s Repository since the time of this initial writing

vRealize Orchestrator REST Hosts and Operations for Rubrik

Thu, 27 Aug 2015 14:30:30 +0000

In part one of this series, we went over some basics about what REST is and the methods involved in it. In this post, we’ll add a REST host and show you how to add some REST Operations. To begin, we need to add a REST host. In plain terms, this is simply a host that will be accepting an API call. In this case, we’re adding the Rubrik Hybrid Cloud Appliance as our REST host.

Getting Started with vRealize Orchestrator and Rubrik's REST API

Tue, 25 Aug 2015 14:00:02 +0000

What’s this REST thing everyone keeps talking about?

“Oh, don’t worry, we have a REST API.”

“It’s just a simple REST call.”

At one point I was hearing these phrases and would get very frustrated. If REST is so commonplace or so simple to use, then why did I not know how to do it? If this sounds like you, then keep reading. I work for a company called “Ahead” as a consultant and they recently got a Rubrik Hybrid Cloud Appliance in their lab but my colleague Nick Colyer and I noticed that they didn’t have any vRealize Orchestrator Plugins for it. We decided to build these on our own, with the help of Chris Wahl and publish them for the community to use.

Getting Started with vRealize Orchestrator and Rubrik's REST API

Tue, 25 Aug 2015 14:00:02 +0000

What’s this REST thing everyone keeps talking about?

“Oh, don’t worry, we have a REST API.”

“It’s just a simple REST call.”