Använder Chef-solo för att konfigurera en Django-app på Ubuntu

Det finns många sätt att automatisera processen för att ställa in och konfigurera en box. Av vilken anledning som helst, om hela vårt system vid det här laget bara består av en enda låda, är det överdrivet att installera en fullständig SCM-infrastruktur (Software Configuration Management). Skalskript är ett alternativ, men vi kan också använda en avskalad version av SCM som finns tillgänglig i några av verktygen där ute. Chef är ett av de populära alternativen och "chef-solo" är Chefs fristående konfigurationsläge där vi inte kräver en extra nod för att fungera som en "kock-server". Allt den behöver är en URL eller en sökväg till ett tarballpaket som innehåller kockkokböcker. Jämfört med skalskript är den här typen av tillvägagångssätt mer deklarativ och effektiv ur lådan och är också en bra introduktion för att komma igång med SCM- eller IaC-processer (Infrastructure as Code).

Några andra fördelar med att använda chef-solo:

• Kompositerbarhet: Använd de gemensamma kokböckerna från kockens snabbköp eller andra ställen.
• Gratis och öppen källkod; licensierad under den tillåtande Apache 2.0-licensen.
• Tillgång till resten av kockens ekosystem (InSpec, ChefSpec, Cookstyle, Foodcritic, chef-shell etc)
• Kokböckerna och recepten kan senare anpassas till ett klient/serverläge.

Och några nackdelar:

• Vissa gemenskapskokböcker på Chef Supermarket är föråldrade, trasiga och inte underhållna.
• Chef-solo kan inte lösa beroenden på egen hand.

'Recepten' inuti en kock 'kokbok' har en rubinbaserad DSL som beskriver att 'resurser' är i ett visst tillstånd på en nod. Låt oss gå vidare med en genomgång för att bekanta oss med några kockkoncept som också är tillämpliga på kock-solo. Vårt mål är att sätta upp en Ubuntu-nod som kör en Python/Django-webbapp med Gunicorn och 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.

(Allt från denna tidpunkt och framåt, om inte annat anges, ska köras på vår maskin, även kallad "Chef Workstation")

Skapar kokboken

Kokböcker i chef är en återanvändbar enhet som innehåller allt som behövs för att stödja ett konfigurationsscenario. Kokböcker kan innehålla flera "recept" och "recept" består mestadels av resursmönster. default.rbär standardreceptet som kommer att köras när kokboken refereras till i en körlista . Olika recept möjliggör separation av bekymmer. För den här handledningen lägger vi dock till alla resursdeklarationer i en huvudreceptfil, som är default.rb.

Skapa en mapp som heter "my-chef-project" och skapa en mapp inuti den som heter "kokböcker". Från ./my-chef-project/cookbooks/, kör:

$ chef generate cookbook my-cookbook

Vår katalogstruktur kommer nu att se ut så här:

.
└── 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

Lägger till paket

Det första steget för att ställa in vår nod är att identifiera vilka paket som krävs av vår app. Vår nod är vald för att vara Ubuntu, så vi kan lita på APT-pakethanteraren för att samla in beroenden. Att installera paketen som tillhandahålls av OS-distributionen är då en bit av kakan:

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'

Dessa är ganska självförklarande. Den första raden kommer att uppdatera apt-förvaret och följande rader kommer att installera dessa paket.

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.

Skapa linux-användare

När vi har lagt till de nödvändiga paketen måste vi skapa en icke-privilegierad Linux-användare som kommer att äga applikationens källkod.

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

Observera att lösenordet är ett shadow hash-format som används i Linux. Det kan härledas med OpenSSL:

$ openssl passwd -1 -salt alilbitof mypassword

Inklusive appkällan

Låt oss nu inkludera Django-applikationens källkod i vår kokbok. Placera källkoden i ./my-chef-project/cookbooks/my-cookbook/files/default/myapp/ Skapa ./my-chef-project/cookbooks/my-cookbook/files/defaultkatalogen om den inte finns.

Instruktioner för att kopiera dessa filer till en avlägsen plats på vår nod beskrivs med hjälp av remote_directory- resursen:

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

Dra in python-beroendena

För att installera python-paketen i requirements.txtkan vi använda exekveringsresursen för att köra ett godtyckligt kommando. I det här fallet måste vi köra kommandot pip installation över 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

Konfigurera Gunicorn & NGINX

Nu är det dags att förbereda Gunicorn WSGI HTTP-servern med NGINX som vår omvända proxy. Nginx används också för att hantera alla statiska tillgångar från Django.

För att koppla upp Gunicorn som en tjänst på Ubuntu kan Systemd användas. Den systemd_unit resurs ingår i Chef sedan 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 måste vi inkludera en standard NGINX proxy-konfiguration till denna Gunicorn-server som visas nedan. Det här utdraget kan gå in i ./my-cookbook/templates/nginx.conf.erb. Skapa mallkatalogen om den inte finns.

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.

För att kopiera över denna konfiguration till webbplatsaktiverad mapp på noden, använd mallresursen från Chef.

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

Aktivering av konfigurationer på nginx görs normalt genom att skapa en symbollänk som pekar på konfigurationen på sites-availablei nginx- sites-enabledmappen. Symboliska länkar kan deklareras i kock kokböcker med länk resurs show nedan:

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

och för att ta bort symbollänken för standardkonfigurationen:

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

Startar NGINX

Och slutligen, för att starta nginx-tjänsten:

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

Runlistor

Körlistor i kock är en ordnad lista med roller eller recept i en kokbok som kommer att köras i sekvens på noden. Vi har en kokbok "min-kokbok" och "standard"-receptet inuti den som vi behöver köra på Ubuntu-rutan, så runlist.json i vår projektkatalog ( ./my-chef-project/runlist.json) bör se ut så här:

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

Sista stegen

Vår kokbok för Chef solo är redo att serveras. Det är dags att tillhandahålla en Ubuntu 18.04-maskin och installera 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 tillbaka till vår kock-arbetsstation behöver vi bara lägga kokboksmappen i en tarball, överföra den tarballen tillsammans med runlist.jsontill fjärrnoden som vi tillhandahållit ovan och kör kommandot chef-solo:

(Kommandot nedan ska köras inuti noden eller "kockklienten" och inte kockarbetsstationen)

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

Eller här är en one-liner (att köras från ./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 är allt! Se standardutmatningen fyllas med kockaktivitet som försöker konvergera din nod till det du har angett i kokböckerna. Chef-solo kommer att installera alla ädelstenar som krävs för alla kokböcker. Om chef-solo-kommandot är framgångsrikt kommer vi att ha en fungerande Django-applikation som körs bakom nginx på Ubuntu-lådan. Navigera till domänen/IP för att testa den.

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

Svara på förändringar

Närhelst vi gör en ändring i innehållet i vår projektkatalog (recept, mallar eller applikationens källkod etc), kör helt enkelt ovanstående one-liner från projektkatalogen.

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ärd för tarballen (valfritt)

Om du tittar noga på det sista chef-solo-kommandot, lägg märke till att det --recipe-urlär tänkt att ta en URL. Detta innebär att du kan ha ett arbetsflöde där en CI bygger din kock-solo tarball, laddar upp den någonstans och konfigurerar din nod att dra från den med jämna mellanrum.

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.