I have been asked many a times what are the several configuration related (note that I am not testing anything but I have learned that doing these configuration changes almost always had me test 1 or 2 things in Eucalyptus) things I do after installing Eucalyptus. I thought of making the list of things that I would normally do to get started with my cloud deployment. By no means this list is exhaustive and please feel free to pitch in your feedback/comments as you feel necessary. The cloud deployment discussed here would be based on Eucalyptus faststart. Obviously I haven’t automated this but that is the next natural step for me to do.
Once the faststart install is finished I would do following things:
a) Add my SSL cert to the CLC. Cannot trust HTTP right ? This URL helps
By default Eucalyptus will come with SSL enabled and a self signed certificate. But most of the clients that I use (example the AWS SDKs etc.) have SSL verification switched ON by default. This causes problem when the self signed certificate verification fails. So for my cloud sub-domain (cloud.jeevanullas.in) I have spent money to buy an SSL cert (with *).
b) Re-direct port 443 to 8773. All Eucalyptus webservice listens on port 8773. Again a non-standard port for my HTTPS communication (via SDKs/tools). I had rather use 443 instead of a custom port. So as per the earlier URL I make sure the system got the iptables re-direct rule going. Make sure this is also set in /etc/sysconfig/iptables so you don’t have to apply it again after a OS restart etc.
c) Install and configure AWS CLI . By no means do I dislike euca2ools. But seriously euca2ools has some lot of catching up to do specially around IAM roles which I use almost all the time along with instance profiles. All my AMI or EMI if you will, have AWS CLI installed or it gets installed on fly. In case you still want to use euca2ools I highly recommend using the euca2ools config file to set your accounts, users and clouds.
d) Enable DNS names for the Eucalyptus webservices and instances. This I do not understand why we don’t do by default. Perhaps maybe our DNS implementation has some serious catching up to do before it can go mainstream?
e) You must have heard of the imaging worker and ELB service in Eucalyptus. Not sure about your experience but I have never had success using them at the first instance. Always ended up troubleshooting something or the other. Once it was NTP, then it was the firewall (security group) and sometimes DNS. All these troubleshooting hours have taught me to enable following properties:
PROPERTY services.imaging.worker.ntp_server PROPERTY services.loadbalancing.worker.ntp_server
Above 2 properties you would like to set if your cloud is running on a restricted network. When the ELB or imaging worker instance boots up they look for to sync their clock with an NTP server on internet. If you don’t have internet access for the instances please update these 2 properties with your organization NTP server IP/hostname.
PROPERTY services.imaging.worker.keyname PROPERTY services.loadbalancing.worker.keyname
In case your imaging worker or ELB aren’t doing the job correctly you will have to troubleshoot further but by default you aren’t allow to login to the imaging worker or ELB instance. You need to make sure a proper keypair is set as value for the above 2 properties before you trigger creation of imaging worker or ELB. You will have to allow SSH in the security group to which the imaging worker or ELB instance belongs. Having SSH access is so useful you will realise when you for example keep looking for a status update via euca-describe-conversion-tasks.
PROPERTY services.imaging.worker.log_server PROPERTY services.imaging.worker.log_server_port
In scenarios’ where I am asked to setup cloud for our customers, I usually set the above 2 properties to point at the ELK stack. This way all logs from imaging worker are available at 1 central place with all goodness of search,filtering etc.
In case you are dealing with raw files or images bigger than the disk size for m1.small instance type you might want to change the above property as well. More on this at our documentation page.
Oh yeah if you are an old Eucalyptus user you might have noticed the difference. Yes the cloud properties have changed. Now we have these properties all prefixed with “services” in case you didn’t get the memo about it please spare a minute or two to read the documentation on it.
f) Well I can’t stress enough on the question of security. If you haven’t done this already please review the ports used by Eucalyptus and ensure you are having a restrictive firewall via iptables on your host machine that only allows connections intended for normal operation of cloud.
Next on the same topic of security ensure you create a new account on your cloud and have a group as well as a user in that group. Don’t use account or cloud administrator API keys. This helps you to plan your deployment and prepare your app for AWS. Follow the best practices.
Ensure your IAM policies are restrictive enough to allow the particular task defined to be perform and not allowing other operations on the cloud. This helps in deploying code to production i.e. AWS (where you save in terms of $$$ and perhaps real security threats coming from a public network).
g) Set the cloudformation region. This I have to do almost always because most of my templates are the same that I use on AWS and are provided here
euca-modify-property -p cloudformation.region=eucalyptus
Above list is by no means an exhaustive list of things someone would do on a new install. Some would like to point MicroQA on their Eucalyptus cloud to perform functional tests against it and ensure things are working fine. But if you are someone out there who prefers to do tweaking with the cloud configuration please feel free to comment on this blog post and I will make sure to add your post setup task to the list.