Brug af Chef-solo til at konfigurere en Django-app på Ubuntu

Der er mange måder at automatisere processen med at opsætte og konfigurere en boks. Uanset årsagen, hvis hele vores system på dette tidspunkt kun består af en enkelt boks, er det overkill at opsætte en fuld SCM (Software Configuration Management)-infrastruktur. Shell-scripts er én mulighed, men vi kunne også bruge en afisoleret version af SCM, som er tilgængelig i et par af værktøjerne derude. Chef er en af ​​de populære muligheder, og "chef-solo" er kokkens selvstændige konfigurationstilstand, hvor vi ikke kræver en ekstra node for at fungere som en "kok-server". Alt det behøver er en URL eller en sti til en tarball-pakke, der indeholder kokke-kogebøger. Sammenlignet med shell-scripts er denne type tilgang mere deklarativ og effektiv ud af boksen og er også en god introduktion til at komme i gang med SCM'er eller IaC-processer (Infrastructure as Code).

Et par andre fordele ved at bruge chef-solo:

• Komponerbarhed: Brug fællesskabets kogebøger fra kokkens supermarked eller andre steder.
• Gratis og open source; licenseret under den tilladelige Apache 2.0-licens.
• Adgang til resten af ​​kokkens økosystem (InSpec, ChefSpec, Cookstyle, Foodcritic, chef-shell osv.)
• Kogebøgerne og opskrifterne kan senere tilpasses til en klient/server-tilstand.

Og nogle ulemper:

• Nogle fælleskogebøger på Chef-supermarkedet er forældede, ødelagte og ikke vedligeholdt.
• chef-solo kan ikke løse afhængigheder alene.

'Opskrifterne' inde i en kokke-'kogebog' har en rubinbaseret DSL, der beskriver, at 'ressourcer' er i en bestemt tilstand på en node. Lad os gå videre med en gennemgang for at stifte bekendtskab med nogle få kokkekoncepter, der også er anvendelige for chef-solo. Vores mål er at opsætte en Ubuntu-node, der kører en Python/Django-webapp ved hjælp af Gunicorn og NGINX.

Note: We do not necessarily require ChefDK to be installed on our "Chef workstation" (our machine), although with it, we can use 'chef generate' commands to start-off with a directory structure for creating cookbooks, recipes and more. In this article, we will assume ChefDK is installed on our workstation. Commands were run using the version 4.7.26-1 of ChefDK.

(Alt fra dette tidspunkt og fremefter, medmindre andet er angivet, skal køres på vores maskine, også kaldet 'Chef Workstation')

Oprettelse af kogebogen

Kogebøger i chef er en genanvendelig enhed, der indeholder alt det nødvendige for at understøtte et konfigurationsscenarie. Kogebøger kan indeholde flere 'opskrifter' og 'opskrifter' består for det meste af ressourcemønstre. default.rber standardopskriften, der køres, når der henvises til kogebogen i en køreliste . Forskellige opskrifter giver mulighed for adskillelse af bekymringer. Til denne øvelse tilføjer vi dog alle ressourcedeklarationer i én hovedopskriftsfil, som er default.rb.

Opret en mappe med navnet "my-chef-project" og opret en mappe inde i den kaldet "kogebøger". Fra ./my-chef-project/cookbooks/, kør:

$ chef generate cookbook my-cookbook

Vores mappestruktur vil nu se sådan ud:

.
└── my-chef-project
└── cookbooks
└── my-cookbook
├── CHANGELOG.md
├── LICENSE
├── Policyfile.rb
├── README.md
├── chefignore
├── kitchen.yml
├── metadata.rb
├── recipes
│ └── default.rb
├── spec
│ ├── spec_helper.rb
│ └── unit
│ └── recipes
│ └── default_spec.rb
└── test
└── integration
└── default
└── default_test.rb

Tilføjelse af pakker

Det første skridt til at konfigurere vores node er at identificere, hvilke pakker der kræves af vores app. Vores node er valgt til at være Ubuntu, så vi kan stole på APT-pakkehåndteringen til at samle afhængighederne. Installation af pakkerne leveret af OS-distributionen er så et stykke kage:

apt_update
package 'python3'
package 'python3-pip'
package 'nginx'
package 'pkg-config'
package 'libcairo2-dev'
package 'libjpeg-dev'
package 'libgif-dev'
package 'libgirepository1.0-dev'

Disse er stort set selvforklarende. Den første linje vil opdatere apt-lageret, og de følgende linjer vil installere disse pakker.

Note: The packages following 'nginx' are needed for compiling some of the python dependencies through pip. These may differ based on your python/django project dependencies specified in requirements.txt. You can use a trial and error method to determine these packages that you need to include in your cookbook. To do that, perform a manual sudo pip install -r requirements.txt (Note: This installs packages system wide!) on a freshly instantiated ubuntu machine to see if it runs successfully. If not, the stderr should give you hints on what packages are missing.

Oprettelse af linux-brugere

Når vi er færdige med at tilføje de nødvendige pakker, skal vi oprette en ikke-privilegeret Linux-bruger, som vil eje applikationens kildekode.

user 'bob' do
  uid 1212
  gid 'users'
  home '/home/bob'
  shell '/bin/bash'
  password '$1$alilbito$C83FsODuq0A1pUMeFPeR10'
end

Bemærk, at adgangskoden er et shadow hash-format, der bruges i Linux. Det kan udledes ved hjælp af OpenSSL:

$ openssl passwd -1 -salt alilbitof mypassword

Inklusiv app-kilden

Lad os nu inkludere Django-applikationens kildekode i vores kogebog. Placer kildekoden inde i ./my-chef-project/cookbooks/my-cookbook/files/default/myapp/ Opret ./my-chef-project/cookbooks/my-cookbook/files/defaultmappen, hvis den ikke findes.

Instruktion til at kopiere disse filer til en fjernplacering på vores node er beskrevet ved hjælp af remote_directory- ressourcen:

remote_directory '/home/bob/myapp' do
  source 'myapp' # This is the name of the folder containing our source code that we kept in ./my-cookbook/files/default/
  owner 'bob'
  group 'users'
  mode '0755'
  action :create
end

Trækker python-afhængighederne ind

For at installere python-pakkerne i requirements.txtkan vi bruge execute- ressourcen til at køre en vilkårlig kommando. I dette tilfælde skal vi udføre pip-installationskommandoen over det:

execute 'install python dependencies' do
  command 'pip3 install -r requirements.txt'
  cwd '/home/bob/myapp'
end

Note: Bear in mind that this is going to execute as the root user and the python libraries will be installed system-wide. If our node is designated to exclusively run this one single python app, then it isn't much of a problem. Despite that, a better option to keep things clean and sane is to find and use a community cookbook that manages python installations or 'virtualenvs'. (or at the very least, write a series of execute blocks to replicate this). Using virtualenvs in python ensures that any python based system tools or other python projects will not be affected

Opsætning af Gunicorn & NGINX

Nu er det tid til at forberede Gunicorn WSGI HTTP-serveren med NGINX som vores omvendte proxy. Nginx bruges også til at håndtere alle de statiske aktiver fra Django.

For at fastgøre Gunicorn som en tjeneste på Ubuntu kan Systemd bruges. Den systemd_unit ressource er inkluderet i Chef siden version 12.11.

systemd_unit 'gunicorn.service' do
  content({
  Unit: {
    Description: 'Django on Gunicorn',
    After: 'network.target',
  },
  Service: {
    ExecStart: '/usr/local/bin/gunicorn --workers 3 --bind localhost:8080 myapp.wsgi:application',
    User: 'bob',
    Group: 'www-data',
    WorkingDirectory: '/home/bob/myapp'
    Restart: 'always',
  },
  Install: {
    WantedBy: 'multi-user.target',
  }
  })
  action [:create, :enable, :start]
end

Nu skal vi inkludere en standard NGINX proxy-konfiguration til denne Gunicorn-server som vist nedenfor. Dette uddrag kan gå ind i ./my-cookbook/templates/nginx.conf.erb. Opret skabelonmappen, hvis den ikke findes.

Note: Chef's templates support embedded ruby files that can contain variables, ruby expressions and statements. Although this file has the 'erb' extension, we did not use any of the ruby statements or expressions. Also, for the sake of simplicity, we only have a non HTTPS nginx config here (gentle reminder; please do not do this in production!)

server {
  listen 80;
  server_name http://example.com/;

  location = /favicon.ico { access_log off; log_not_found off; }
  location /static/ {
    root /home/bob/myapp/myapp/static;
  }

  location / {
  include proxy_params;
    proxy_pass http://localhost:8080/;
  }
}

Note: There is also an alternative and a better config, where, for instance the Gunicorn server is bound to a unix domain socket instead of a TCP loopback connection. It's worth exploring that for performance reasons.

Brug skabelonressourcen fra Chef for at kopiere denne konfiguration til webstedsaktiveret mappe på noden .

template '/etc/nginx/sites-available/example.com.conf' do
  source 'nginx.conf.erb'
  owner 'root'
  group 'root'
  mode '0744'
end

Aktivering af konfigurationer på nginx udføres normalt ved at oprette et symlink, der peger på konfigurationen på sites-availablei nginx's sites-enabledmappe. Symlinks kan erklæres i kok kogebøger med link ressource som vist nedenfor:

link '/etc/nginx/sites-enabled/example.com.conf' do
  to '/etc/nginx/sites-available/example.com.conf'
end

og for at slette standardkonfigurationens symbollink:

link '/etc/nginx/sites-enabled/default' do
  action :delete
end

Starter NGINX

Og til sidst, for at starte nginx-tjenesten:

service 'nginx' do
  action :enable
  action :start
end

Løbelister

Kørselslister i kok er en ordnet liste over roller eller opskrifter i en kogebog, som vil blive udført i rækkefølge på noden. Vi har en kogebog "min-kogebog" og "standard"-opskriften inde i den, som vi skal udføre på Ubuntu-boksen, så runlist.json i vores projektmappe ( ./my-chef-project/runlist.json) skulle se sådan ud:

{
  "run_list": [
    "recipe[my-cookbook::default]"
  ]
}

Afsluttende trin

Vores kogebog til Chef solo er klar til at blive serveret. Det er tid til at klargøre en Ubuntu 18.04-maskine og installere ChefDK på den:

$ ssh [email protected] 'apt-get update && yes | apt-get install curl && curl https://packages.chef.io/files/current/chefdk/4.7.45/ubuntu/18.04/chefdk_4.7.45-1_amd64.deb -o chefdk.deb && yes | dpkg -i chefdk.deb && rm chefdk.deb'

Når vi går tilbage til vores Chef-arbejdsstation , er alt, hvad vi skal gøre, at lægge kogebogsmappen inde i en tarball, overføre den tarball sammen med den runlist.jsontil den eksterne node, vi klargjorde ovenfor, og køre chef-solo-kommandoen:

(Kommandoen nedenfor skal køres inde i noden eller 'kokklienten' og ikke Chef Workstation)

$ chef-solo --recipe-url $(pwd)/chef-solo.tar.gz -j $(pwd)/runlist.json --chef-license=accept

Eller her er en one-liner (skal køres fra ./my-chef-project/CWD på Chef Workstation):

tar zvcf chef-solo.tar.gz ./cookbooks &&\
scp chef-solo.tar.gz runlist.json [email protected]:~/ &&\
ssh [email protected] 'chef-solo --recipe-url $(pwd)/chef-solo.tar.gz -j $(pwd)/runlist.json --chef-license=accept'

Det er det! Se standardoutputtet fyldes op med kokkeaktivitet, der forsøger at konvergere din node til det, du har angivet i kogebøgerne. Chef-solo installerer alle de ædelstene, der kræves til alle kogebøgerne. Hvis chef-solo-kommandoen er vellykket, vil vi have en fungerende Django-applikation, der kører bag nginx på Ubuntu-boksen. Naviger til domænet/IP for at teste det.

Note: Remember that in django you may need to set this domain/ip in the ALLOWED_HOSTS list in settings.py.

Reagerer på ændringer

Når vi foretager en ændring i indholdet af vores projektmappe (opskrifter, skabeloner eller applikationens kildekode osv.), skal du blot køre ovenstående one-liner fra projektbiblioteket.

Tip: If the cookbook is version controlled with git (as it should), one good recommendation is to set git hooks to run this one-liner.

Vært for tarballen (valgfrit)

Hvis du ser nærmere på den sidste chef-solo-kommando, skal du bemærke, at den --recipe-urler beregnet til at tage en URL. Dette betyder, at du kan have en arbejdsgang, hvor en CI vil bygge din chef-solo tarball, uploade den et sted og konfigurere din node til at trække fra den med jævne mellemrum.

Tip: Use curl to pull the changed tarball periodically as a cronjob. curl -z $file will honor If-Modified-Since headers and will only download the tar ball if the remote file has been changed since the timestamp on the existing local $file.