Durante las últimas semanas, he estado investigando mucho a Chef. Aunque la documentación es buena, ha habido muchas ocasiones en las que me quedé atascado sin ninguna pista. Así que daré una introducción detallada a Chef. Si no has oído hablar del Chef (como yo hace unos meses) no te preocupes, te lo explicaré todo.

¿Qué es Chef y por qué?
Chef es una poderosa plataforma de automatización que transforma la infraestructura en código. Chef automatiza cómo se configura, implementa y administra la infraestructura en su red, sin importar su tamaño.Pero, ¿qué significa infraestructura como código? Entonces, digamos que tiene una aplicación Java que debe implementarse en una sola máquina. No necesita automatización para eso, puede hacerlo manualmente.
Pero, ¿qué sucede cuando una sola máquina no puede manejar la carga y necesita implementar su aplicación en 10, 50 o 100 máquinas más? Aquí es donde entra Chef. En lugar de implementar manualmente su aplicación en cada máquina, puede escribir código que lo haga por usted.

Terminología
- Estación de trabajo: su máquina local, también conocida como computadora portátil. Aquí es donde escribe su código que luego se envía a su servidor chef.
- Chef Server: aquí es donde reside todo su código. También contiene toda la información sobre los nodos.
- Nodos, también conocidos como Chef Client: las máquinas en las que debe ejecutarse su código. Puede usar algo como vagrant con fines de aprendizaje y aws / gcp en producción. Sus nodos extraen el código más reciente de su servidor chef.
Empezando con chef
Para comenzar, primero debemos instalar ChefDK en nuestra estación de trabajo. ChefDK es el kit de desarrollo de Chef que contiene todas las herramientas necesarias para comenzar a utilizar Chef. Puede instalar ChefDK desde aquí.
Una vez que haya instalado ChefDK, ejecute el siguiente comando:
chef generate cookbook testingCheftree testingChef

Esta es la estructura que genera el comando chef generate cookbook . Repasemos cada archivo para ver qué hacen.
Libros de cocina
Un libro de recetas es la unidad fundamental de configuración que tiene como objetivo lograr un estado deseado con la ayuda de otros componentes como recetas, plantillas, archivos, etc. De forma predeterminada, cuando genera un libro de recetas, solo obtiene una carpeta de recetas. Sin embargo, también puede crear carpetas para plantillas y otros componentes si planea usarlos (hablaremos de ellos más adelante).
Digamos que desea ejecutar una aplicación Java en una máquina. Hay dos cosas que se requieren para eso:
- Su máquina debe tener java instalado.
- Debe tener la aplicación para ejecutarse.
Entonces puedes ejecutar la aplicación.
Así que crea un libro de recetas que, cuando se ejecuta en un nodo, instala Java en ese nodo, recupera la aplicación que debe ejecutar y ejecuta esa aplicación.
Recursos del chef
Un recurso es un bloque Ruby con cuatro componentes: un tipo, un nombre, una (o más) propiedades (con valores) y una (o más) acciones. La sintaxis de un recurso es la siguiente:
type 'name' do attribute 'value' action :type_of_actionend
Supongamos que desea instalar OpenJDK 7 en su nodo. Para hacerlo, puede utilizar el recurso del paquete disponible en chef.
package 'java-1.7.0-openjdk' do action :installend
La acción: instalar es la acción predeterminada para el recurso del paquete, por lo que puede omitirla si lo desea.
package 'java-1.7.0-openjdk'
Para ejecutar un cronJob en su nodo, puede usar el recurso cron .
cron 'reporting' do action :create minute '0' hour '0' weekday '1' command "/srv/app/scripts/daily_report" # Path of script to runend
Dependiendo de lo que quieras lograr, hay muchos recursos de chef incorporados que puedes usar. Puedes leer más sobre ellos aquí.
Recetas
Una receta es una colección de recursos que tiende a acercar su nodo un paso más al estado deseado. Las recetas están escritas en rubí.
Para ejecutar una receta, usamos el siguiente comando:
chef-client -z pathToRecipe
La -z
bandera implica que el chef-cliente debe ejecutarse en modo local ya que no estamos conectados a ningún servidor chef. En caso de que sus nodos estén conectados al servidor, no tiene que usar la -z
bandera.
************************** default.rb ****************************
/* This is an example recipe to install install httpd (Apache HyperText Transfer Protocol (HTTP) server program), creates a file on the node at /var/www/html/index.html (default path for serving web pages on apache server) and starts the service on a centOS based machine */
package 'httpd'
file '/var/www/html/index.html' do content 'This is a placeholder for the home page.'end
service 'httpd' do action [:enable, :start]end
Metadatos y Berksfile
Cuando trabaje en un libro de cocina, no tiene que comenzar desde el primer paso, ya que existe una buena posibilidad de que alguien ya haya creado algo similar y pueda simplemente extender su trabajo.
This is where the Chef Supermarket comes in. It contains community cookbooks which you can use as dependencies in your own cookbook. These dependencies are listed in the metadata.rb file or even in your Berksfile. But then the question arises: how are they different?
************************* Berksfile ********************************source '//supermarket.chef.io' # Fetch dependencies from here
metadata
When you upload your cookbook on the chef server, you must also upload your cookbook’s dependencies. This is where Berks help. You just have to run two simple commands:
berks install berks upload
which download all the dependencies of your cookbooks and upload all of them to the chef server. The dependency cookbooks are present at
~/.berkshelf/cookbooks/
In case you updated your cookbook and want to re-upload them on the chef server, then you must update the version in the metadata file. Otherwise when you use the berks upload command, the new recipe won’t be uploaded unless you force an upload.
**************************** metadata.rb ***************************name 'testingChef'maintainer 'The Authors'maintainer_email '[email protected]'license 'All Rights Reserved'description 'Installs/Configures testingChef'long_description 'Installs/Configures testingChef'version '0.1.0' # Update after changes are made to the cookbookchef_version '>= 12.14' if respond_to?(:chef_version)
depends 'haproxy', '~> 6.2.6'
Chefignore
Put files/directories that should be ignored in this file when uploading
or sharing cookbooks to the community site.
Ohai
When we install CheckDK, we also get ohai with it. Every time you run chef-client on your node, chef runs ohai before that. Ohai collects a lot of system information. The types of attributes Ohai collects include, but are not limited to:
- Operating System
- Network
- Memory
- Disk
- CPU
When running ohai you get a lot of output, so be mindful of what you want and write your commands accordingly.



Now if want, we can use all this information in our recipes. All we have to do is refer to a particular property of the node.
if node['hostname'] == "Some hostname" do // do something only if the nodes hostname matchesend
Knife
Knife is a tool which you use to communicate with the chef server. If you want to know anything about your nodes or want to update anything like their recipes, knife is the way to go. There are more than a dozen knife commands. Here are some of them
- knife bootstrap— This command is used to create a new node and attach that to your chef server. When bootstrapping a node, chef installs everything like ohai, chef-client on the node and it also runs chef-client automatically. For any subsequent changes made to that node, you need to run chef-client manually to update your node.
- knife node show ${nodeName} — This command is used to get information about your node which includes recipes, environment, platform etc.

3. knife cookbook list ${nodeName} — This command is used to get all the cookbooks associated with your node

That’s about it ! Thank you for reading, and I hope you enjoyed the article.
You can follow me on Medium and Github :)