Rodolfo Cordero –DevOps in intive-FDV – recently gave us a series of talks to explain how Chef and AWS OpsWorks work respectively, and the pros and snags of using one or the other tool when automating the process of infrastructure. Here, we are sharing all we have learnt.
Chef and Chef Server
Manual documentation management gets more complex increasingly faster before the need for change that appears every day and is permanently exposed to human error. To overcome these shortcomings, the areas of Operations and Infrastructure normally use scripts such as Bash – in the case of Linux – or Powershell – in the case of Windows -. Snapshots can also be used (images or basic screenshots of the present situation).
But as the number of servers grow, or when lots of small changes exist (such as in IP addresses, environment variables), the documentation goes out-of-date. To work out these difficulties, an array of tools is used. Namely:
- Puppet: It is more focused on the members of the Operations Area; coded in Ruby, with a customized layer.
- Ansible: It is written in Python and uses YAML or Json. It does not offer Windows support.
- Saltstack: It is Python-based and uses YAML for its code
- Chef: It is more oriented to developers who go to Operations. It is Ruby-based.
On this article, we will talk about the latter that allows us to use all the potential of the language, it has integration with Chef Spec, Rubocop and other Ruby libraries and supports Linux and Windows Server.
Chef is a tool built on Ruby which automates supply procedures. It has a service on supermarket.chef.io that works as a forum for people to share their cookbooks with the community and companies.
There are three versions that Chef Software Inc. offers:
- Solo: It is a version that works as a Chef client where no Chef Server is needed, using a local mode.
- Zero: It is meant for testing. It is ideal to test different cookbooks on different operating systems.
- Server: It is an enterprise product, where cookbooks and variables are centralized. Furthermore, different servers can be set up by a single command line. It also boasts a dashboard to visualize status among nodes in real time.
Chef Server works this way:
In the graph we can only see a node or server, but Chef Server is scalable up to the number of servers we need to set up. Here we share a graphic explanation on how the supply process of a node on Chef works:
The solutions offered by Amazon for infrastructure vary in complexity. They offer alternatives that allow us to define absolutely everything and get more control – such as AWS Cloud Formation and EC2 – and options that allow for only opening apps – such as Elastic Beankstalk -. OpsWorks is an intermediate solution between both levels.
Chef Server allows for:
- A completely managed Chef server
- A group of automation tools for workflows that reach continuous implementation, automatic tests to achieve conformity and security, plus a user interface displaying the nodes and their status.
- The Chef server stores tasks and configurations centrally and offers them to each computing node in any scale, from very few nodes to thousands of them.
- OpsWorks for Chef Automate is fully compliant with the tools and guides from the Chef community and records new nodes automatically with its Chef server.
- It allows for management of applications and servers on AWS and on-premise
- Its application is designed as a stack to contain different layers, as load balance, database and server of applications.
- It can implement and set up Amazon EC2 instances in each layer or connect other resources such as Amazon RDS databases.
- OpsWorks Stacks allows you to define automatic scaling for servers, based on pre-established metrics or responding to levels of alerts, either by CPU and/or RAM usage, among others, using the CloudWatch service.
- Chef Server works during the stage of creating the machines and the supply, but does not complete the process of launching the application. Instead, OpsWorks Stacks goes all the way until the end by using other Amazon services.
- No additional charges are required to use OpsWorks Stacks for Amazon EC2, you only pay for underlying resources which are created by the use of OpsWorks Stacks. By contrast, with OpsWorks for Chef Automate, charges are based on the amount of nodes connected to your Chef server and the running-time in each node. An Elastic IP must be available and you also need to pay for the instance of Amazon Elastic Compute Cloud (Amazon EC2) which runs in the Chef server.
- You cannot set up configurations for hybrid servers. You have to choose between Windows or Linux. Instead, in Chef Server you can do so.
- OpsWorks Stacks is only available in: US East (N. Virginia), US West (Oregon) and EU (Ireland).
In conclusion, Rodolfo affirmed that the decision depends on each project. Using one or the other alternative will depend on whether we had already been using Chef – in which case Chef Server will be more convenient-; or if we are starting the automation path from scratch; if this is the case, OpsWorks Stacks will be more convenient.