You have the shared document open and the phone rings. The interviewer, at the other end of the line, starts with a thick accent:
– What does ls * do?
You cannot believe your ears: it sounds easy. Really easy. So you answer in the line of “it lists all the files in the current directory”. The interviewer follows up with one or 2 questions on how it really works and you answer about the star being passed as a parameter to ls and how the binary interprets it in some way that it gets the entire directory walked over and its contents listed. Simple!
CloudFormation is the core functionality provided by Amazon Web Services in the area of expressing infrastructure as code. One can write the infrastructure design in either JSON and YAML (with similar syntax keywords); there is also a template designer that may help in putting together the infrastructure elements and their dependencies. The particular details of each resource being defined must be coded out, though.
There are no limitations on the types of resources that can be brought up, as far as I noticed – each resource type provided by Amazon can be coded and subsequently created and provisioned. One can also define an explicit order (e.g. some resource to be created before another), apart from the implicit order that can be deduced (e.g. if an EC2 instance is defined with a IAM Role, the role is always created before the instance). The revert process is also clean: deleting the CloudFormation stack does delete everything created by the stack itself; nothing gets left behind.
The setup was performed on a freshly installed CentOS 6 VM using a “minimal ISO” image from the CentOS Project website. The VM was set up on a local VirtualBox installation, all settings being left to default except for the memory which was increased from 512Mb to 1Gb. Of course, the more, the better, but 1Gb is the lowest one can go without facing serious memory swapping.
The successful Centos 6 installation leaves the external network interface disabled upon the initial boot, so this must be fixed before anything else. One must look into /etc/sysconfig/network-scripts/ifcfg-eth0 and change the ONBOOT parameter from no to yes. Afterwards, the network subsystem must be restarted, e.g.:
# vi /etc/sysconfig/network-scripts/ifcfg-eth0 ... ONBOOT=yes ... # service network restart
Once the VM gets Internet access, it’s a good practice to update everything and reboot it before going forward with the Chef Server installation:
# yum -y update # reboot
There is one important change one must perform in order to get the Chef Server properly set up: the hostname, as localhost.localdomain won’t do. The hostname must also be associated to a static IP address, which can be achieved in VirtualBox by playing with some networking settings (not presented here).
Inside the VM, this is easy to put in place: