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. ...
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. ...
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. ...
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? ...
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. ...
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 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. ...
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. ...
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 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. ...