En komplet begyndervejledning til kok og infrastruktur som kode

I de sidste par uger har jeg gravet meget i kok. Selvom dokumentationen er god, har der været mange gange, hvor jeg sad fast uden nogen anelse. Så jeg vil give en grundig introduktion til kokken. Hvis du overhovedet ikke har hørt om kok (ligesom mig for et par måneder tilbage), skal jeg forklare det hele.

Hvad er kok og hvorfor?

Chef er en stærk automatiseringsplatform, der omdanner infrastruktur til kode. Chef automatiserer, hvordan infrastruktur konfigureres, implementeres og administreres på tværs af dit netværk, uanset dens størrelse.

Men hvad betyder infrastruktur som kode? Så lad os sige, at du har et Java-program, der skal implementeres på en enkelt maskine. Du har ikke brug for automatisering til det - du kan gøre det manuelt.

Men hvad sker der, når en enkelt maskine ikke kan håndtere belastningen, og du har brug for at implementere din applikation på 10 eller 50 eller 100 maskiner mere? Det er her, Chef kommer ind. I stedet for manuelt at implementere din applikation på hver enkelt maskine, kan du skrive kode, der gør det for dig.

Terminologi

  1. Workstation - din lokale maskine, også kaldet din bærbare computer. Det er her, du skriver din kode, som derefter skubbes til din kokserver.
  2. Chef Server - Det er her al din kode ligger. Det indeholder også alle oplysninger om noder.
  3. Noder aka Chef Client - De maskiner, hvor din kode skal køre. Du kan bruge noget som vagrant til læringsformål og aws / gcp i produktionen. Dine noder trækker den nyeste kode fra din kokserver.

Kom godt i gang med kok

For at komme i gang skal vi først installere ChefDK på vores arbejdsstation. ChefDK er kokkeudviklingssættet, der indeholder alle de værktøjer, der kræves for at begynde at bruge kok. Du kan installere ChefDK herfra.

Når du har installeret ChefDK, skal du køre følgende kommando:

chef generate cookbook testingCheftree testingChef

Dette er den struktur, der genereres af chefgenerere cookbook kommando. Lad os gå gennem hver fil for at se, hvad de gør.

Kogebøger

En kogebog er den grundlæggende konfigurationsenhed, der sigter mod at opnå en ønsket tilstand ved hjælp af andre komponenter som opskrifter, skabeloner, filer osv. Når du genererer en kogebog, får du som standard kun en opskriftsmappe. Du kan dog oprette mapper til skabeloner og andre komponenter også, hvis du planlægger at bruge dem (vi taler om dem senere).

Lad os sige, at du vil køre en java-applikation på en maskine. Der er to ting, der kræves til det:

  1. Din maskine skal have java installeret.
  2. Det skal have applikationen til at køre.

Derefter kan du køre applikationen.

Så du opretter en kogebog, som, når den køres på en node, installerer java på den node, henter den applikation, du skal køre, og kører den applikation.

Kokkens ressourcer

En ressource er en Ruby-blok med fire komponenter: en type, et navn, en (eller flere) egenskaber (med værdier) og en (eller flere) handlinger. Syntaksen for en ressource er sådan:

type 'name' do attribute 'value' action :type_of_actionend

Lad os sige, at du vil installere OpenJDK 7 på din node. For at gøre det kan du bruge den pakkeressource, der er tilgængelig i kokken.

package 'java-1.7.0-openjdk' do action :installend

Den handling: installere er standardhandlingen for pakke ressource, så du kan springe, at hvis du ønsker.

package 'java-1.7.0-openjdk'

Hvis du vil køre en cronJob på din node, kan du bruge cron- ressourcen.

cron 'reporting' do action :create minute '0' hour '0' weekday '1' command "/srv/app/scripts/daily_report" # Path of script to runend

Afhængigt af hvad du vil opnå, er der mange indbyggede kokressourcer, du kan bruge. Du kan læse mere om dem her.

Opskrifter

En opskrift er en samling ressourcer, der har tendens til at bringe din node et skridt tættere på den ønskede tilstand. Opskrifter er skrevet i rubin.

For at køre en opskrift bruger vi følgende kommando:

chef-client -z pathToRecipe

Den -zflag indebærer, at kokken-klient skal køres i lokal tilstand, da vi ikke har forbindelse til enhver kok server. Hvis dine noder er forbundet til serveren, behøver du ikke bruge -zflag.

************************** 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

Metadata og Berksfile

Når du arbejder på en kogebog, behøver du ikke starte fra det allerførste trin, da der er en god chance for, at nogen allerede har bygget noget lignende, og du bare kan udvide deres arbejde.

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

  1. 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.
  2. knivknude viser $ {nodeName} - Denne kommando bruges til at få oplysninger om din knude, som inkluderer opskrifter, miljø, platform osv.

3. knivkogebogsliste $ {nodeName} - Denne kommando bruges til at hente alle de kogebøger, der er knyttet til din knude

Det handler om det! Tak for din læsning, og jeg håber, at du nød artiklen.

Du kan følge mig på Medium og Github :)