Imperialwicket – immutable infrastructure for bootstrappers: asgard and aws
Immutable Infrastructure for Bootstrappers: Asgard and AWS
This publish belongs to series on my small implementation of immutable infrastructure for bootstrapped projects. You’ll find another posts here:
Introduction
An immutable infrastructure virtual machine
Fundamental AMI generation with Packer
Deploying your AMI with Asgard
Releases, automation, and then steps
If you discover this implementation interesting, you’ll have a book I’m writing about this subject: Immutable Infrastructure with Netflix OSS.
VirtualBox and Vagrant
We want an online machine provider and Vagrant for handling the virtual machines. I’ll be using VirtualBox (4.3.x on Linux) and Vagrant (1.7.x). Install these, and a few knowledge of vagrant’s instructions (up, provision, ssh, halt, and destroy particularly) is going to be useful. I’ll attempt to give all of the instructions clearly, but I won’t spend enough time explaining what they’re accomplishing.
Amazon . com Web Services IAM user and profile
As detailed in the last publish, we’re running Asgard (and finally Packer) inside a virtual machine. Before we are able to run Asgard effectively around the virtual machine, we must have IAM credentials as well as an Amazon . com Web Services account id. I suggest using AWS: IAM->Users to produce a user specific to Asgard. Produce a user with keys, after which assign an inline policy such as this one. That policy is obtained from the Asgard wiki, but uses more open autoscaling and ec2 policies to match just one policy (Amazon . com Web Services limits how big IAM policies). Your bank account id can be obtained through the AWS Management Console when logged in as the root user.
Launching and Configuring the Virtual Machine
With AWS credentials available, we are able to clone my immutable infrastructure for bootstrappers project, and obtain began:
Reviewing Vagrantfile and bootstrap.sh, we have seen that Vagrant imports an Ubuntu/Trusty64 image after which runs the bootstrapping script. Bootstrapping includes updating apt, installing a jdk and tomcat, grabbing the most recent Asgard and Packer, and copying some scripts/configs. This method will require a couple of minutes when completed you need to see something similar to:
You can now use vagrant ssh to connect with the virtual machine, and run the /vagrant/asgardConfig/set-aws-creds.sh script to insert your AWS credentials within the spots. Before blindly supplying AWS credentials (which are fairly effective within this scenario), you need to most likely make sure the code to determine what has been done together. Running the script need to look like:
Inserting credentials in /var/lib/tomcat7/Config.groovy.
* Beginning Tomcat servlet engine tomcat7 [ OK ]
Asgard is going to be offered by your host machine at:
http://localhost:8181
vagrant@ii4bootstrappers:~$
In case your Access Key Id and Secret Access Key are accurate and also the IAM policy is suitable, you will be able to navigate to [http://localhost:8181] in your host machine and find out the Asgard web interface:
The UI requires a little becoming accustomed to, but we will only require a small part of Asgard’s features to handle a little bootstrapped-inspired project. However, I believe there’s hardly any overhead to deploying and managing AMIs in this manner, as well as your project will have to grow very substantially before Asgard starts to become scalability issue (running it on the VM would most likely have to change before it got that far).
Troubleshooting
Inevitably things will go wrong. The typical culprits listed here are:
Inaccurate AWS credentials (Asgard can’t fetch data from/regarding your AWS account because of permissions)
Inappropriate IAM profile (Asgard will get errors from AWS that it may not develop a request because of permissions)
Resource issues for Tomcat (OOM, kernel shut lower)
More details is probably obtainable in /var/log/tomcat7. Catalina.out and asgard.log are particularly helpful.
Next steps
Within the next publish we’ll review a few of the Asgard-specific concepts (Apps and Clusters), produce a working AMI building process with Packer, and obtain everything prepared to deploy the very first form of a really fundamental sample application.
