Konfigurera servern för att distribuera Rails-applikationer med Ansible

För inte så länge sedan behövde jag skriva flera Ansible-playbooks för att förbereda en server för utplacering av en Rails-applikation. Och, till min förvåning, hittade jag ingen enkel steg-för-steg-manual. Jag ville inte bara kopiera någon annans playbook utan att förstå vad som försiggick, och slutligen var jag tvungen att läsa dokumentationen och samla allt själv. Kanske kan jag hjälpa någon att påskynda denna process med hjälp av denna artikel.

Först och främst är det viktigt att förstå att Ansible ger dig ett bekvämt gränssnitt för att utföra en förutbestämd lista av åtgärder på en avlägsen server (eller flera) via SSH. Här finns ingen magi; du kan inte bara installera ett plugin och få en zero-downtime-deploy av din applikation med Docker, övervakning och andra godbitar direkt. För att skriva en playbook måste du veta exakt vad du vill göra och hur du ska göra det. Därför är jag inte nöjd med färdiga playbooks från GitHub, eller artiklar i stil med: "Kopiera och kör, det fungerar."

Vad behöver vi?

Som jag redan nämnt, för att skriva en playbook måste du veta vad du vill göra och hur. Låt oss fastställa vad vi behöver. För en Rails-applikation kommer vi att behöva några systempaket: nginx, postgresql (redis, osv.). Utöver detta behöver vi en specifik version av Ruby. Det är bäst att installera det via rbenv (rvm, asdf…). Att köra allt som root-användare är alltid en dålig idé, så vi måste skapa en separat användare och ställa in rättigheter för den. Efter det är det nödvändigt att ladda upp vår kod till servern, kopiera konfigurationerna för nginx, postgres, osv. och starta alla dessa tjänster.

Till slut är sekvensen av åtgärder följande:

1. Logga in som root
2. installera systempaketen
3. skapa en ny användare, sätta upp rättigheter och SSH-nyckel
4. konfigurera systempaketen (nginx, osv.) och starta dem
5. Skapa en användare i databasen (eventuellt skapa databasen samtidigt)
6. Logga in som den nya användaren
7. Installera rbenv och Ruby
8. Installera Bundler
9. Ladda upp applikationskoden
10. Starta Puma-servern

Dessutom kan de sista stegen utföras med hjälp av Capistrano; åtminstone kan den helt enkelt kopiera koden till releasekatalogerna, växla release via symlink vid en lyckad utplacering, kopiera konfigurationer från en delad katalog, starta om Puma, osv. Allt detta kan göras med Ansible, men varför?

Filstruktur

Ansible har en strikt filstruktur för alla sina filer, så det är bäst att hålla allt i en separat katalog. Det spelar inte så stor roll om den ligger i rails-applikationen eller separat. Man kan lagra filer i ett separat git-repo. Personligen tycker jag att det är mest praktiskt att skapa en katalog ansible i /config-katalogen av rails-applikationen och lagra allt i en och samma repo.

Enkel Playbook

En playbook är en yml-fil som med hjälp av ett specialsyntax beskriver vad och hur Ansible ska göra. Låt oss skapa vår första playbook som inte gör något:

---
- name: Enkel playbook
  hosts: all

Här säger vi helt enkelt att vår playbook kallas Enkel Playbook och att dess innehåll ska köras för alla värdar. Vi kan spara den i /ansible-katalogen med namnet playbook.yml och försöka köra:

ansible-playbook ./playbook.yml

PLAY [Enkel Playbook] ************************************************************************************************************************************
skipping: no hosts matched

Ansible säger att den inte känner till några värdar som motsvarar listan all. De måste upprättas i en särskild inventory-fil.

Låt oss skapa den i samma ansible-katalog:

123.123.123.123

Så här skriver vi bara in värden (idealiskt VPS-värden för tester, eller så kan man ange localhost) och sparar den med namnet inventory.
Vi kan prova att köra Ansible med inventory-filen:

ansible-playbook ./playbook.yml -i inventory
PLAY [Enkel Playbook] ************************************************************************************************************************************

TASK [Gathering Facts] ************************************************************************************************************************************

PLAY RECAP ************************************************************************************************************************************

Om du har ssh-åtkomst till den angivna värden kommer Ansible att ansluta och samla information om det fjärrsystemet. (standard TASK [Gathering Facts]) varefter den ger en kort rapport om körningen (PLAY RECAP).

Som standard används det användarnamn du är inloggad med i systemet för att ansluta. Det kommer troligtvis inte att finnas på värden. I playbook-filen kan du specificera vilket användarnamn som ska användas för anslutning med hjälp av direktivet remote_user. Sådan information om det fjärrsystemet kan ofta vara onödig och man bör inte slösa tid på att samla den. Den uppgiften kan också stängas av:

---
- name: Enkel playbook
  hosts: all
  remote_user: root
  become: true
  gather_facts: no

Försök att köra playbook igen och se till att anslutningen fungerar. (Om du angav root-användaren måste du också ange direktivet become: true för att få förhöjda rättigheter. Som anges i dokumentationen: become inställt på ‘true’/’yes’ för att aktivera privilegierad eskalering. även om det inte är helt klart varför).

Du kan få ett fel orsakat av att ansible inte kan bestämma python-tolk, då kan du ange den manuellt:

ansible_python_interpreter: /usr/bin/python3 

där python ligger kan du ta reda på med kommandot whereis python.

Installation av systempaket

Den standardinstallation som Ansible innehåller många moduler för att arbeta med olika systempaket, vilket gör att vi inte behöver skriva bash-skript för varje ärende. Nu behöver vi en av dessa moduler för att uppdatera systemet och installera systempaket. Jag har Ubuntu Linux på min VPS, så för att installera paket använder jag apt-get och modulen för det. Om du använder ett annat operativsystem kan det hända att en annan modul behövs (kom ihåg att jag i början sa att man bör veta vad och hur vi ska göra). Syntaxen kommer förmodligen att vara liknande.

Vi kompletterar vår playbook med de första uppgifterna:

---
- name: Enkel playbook
  hosts: all
  remote_user: root
  become: true
  gather_facts: no

  tasks:
    - name: Uppdatera system
      apt: update_cache=yes
    - name: Installera systemberoenden
      apt:
        name: git,nginx,redis,postgresql,postgresql-contrib
        state: present

Task — det är just den uppgift som ansible kommer att utföra på de fjärrservrar. Vi ger uppgiften ett namn för att kunna följa dess utförande i loggen. Och beskriver med hjälp av syntaxen för den specifika modulen vad den behöver göra. I det här fallet apt: update_cache=yes — säger att systempaketen ska uppdateras med hjälp av modulen apt. Den andra kommandot är något mer komplicerat. Vi skickar en lista med paket till modulen apt, och säger att deras state ska bli present, vilket betyder att vi ber att installera dessa paket. På liknande sätt kan vi be dem att ta bort eller uppdatera, helt enkelt genom att byta state. Observera att vi behöver paketet postgresql-contrib för att få rails att fungera med postgresql, vilket vi nu installerar. Det här behöver man också veta och göra, ansible gör inte detta själv.

Försök att köra playbook igen och kontrollera att paketen installeras.

Skapar nya användare.

För att arbeta med användare har Ansible också en modul - user. Vi lägger till ännu en task (jag har döljt välkända delar av playbooken med kommentarer för att inte kopiera den helt varje gång):

---
- name: Enkel playbook
  # ...
  tasks:
    # ...
    - name: Lägg till en ny användare
      user:
        name: my_user
        shell: /bin/bash
        password: "{{ 123qweasd | password_hash('sha512') }}"

Vi skapar en ny användare, ställer in en schell och ett lösenord. Och vi stöter genast på flera problem. Vad händer om användarnamnen måste vara olika för olika värdar? Att lagra lösenord i klartext i playbooken är verkligen en dålig idé. Först flyttar vi användarnamnet och lösenordet till variabler, och längre fram i artikeln visar jag hur man krypterar lösenordet.

---
- name: Enkel playbook
  # ...
  tasks:
    # ...
    - name: Lägg till en ny användare
      user:
        name: "{{ user }}"
        shell: /bin/bash
        password: "{{ user_password | password_hash('sha512') }}"

Genom att använda dubbla klammerparenteser i playbooks sätts variabler.

Variabelvärdena anger vi i inventory-filen:

123.123.123.123

[all:vars]
user=my_user
user_password=123qweasd

Observera direktivet [all:vars] – det indikerar att den följande textblocken är variabler (vars) och de gäller för alla värdar (all).

Det är också intressant konstruktion "{{ user_password | password_hash('sha512') }}". Det handlar om att ansible inte skapar användaren via user_add som du skulle göra manuellt. Utan lagrar all information direkt, vilket innebär att vi också måste förvandla lösenordet till en hash i förväg, vilket denna kommandon gör.

Låt oss lägga till vår användare i sudo-gruppen. Men först måste vi se till att en sådan grupp finns, för ingen annan kommer att göra detta åt oss:

---
- name: Enkel playbook
  # ...
  tasks:
    # ...
    - name: Säkerställ en 'sudo' grupp
      group:
        name: sudo
        state: present
    - name: Lägg till en ny användare
      user:
        name: "{{ user }}"
        shell: /bin/bash
        password: "{{ user_password | password_hash('sha512') }}"
        groups: "sudo"

Allt är ganska enkelt, vi har också en modul group för att skapa grupper, med en syntax som liknar apt. Efter det räcker det att ange denna grupp för användaren (groups: "sudo").
Det är också bra att lägga till en ssh-nyckel för denna användare så att vi kan logga in under denna användare utan lösenord:

---
- name: Enkel playbook
  # ...
  tasks:
    # ...
    - name: Säkerställ 'sudo'-grupp
      group:
      name: sudo
        state: present
    - name: Lägg till en ny användare
      user:
        name: "{{ user }}"
        shell: /bin/bash
        password: "{{ user_password | password_hash('sha512') }}"
        groups: "sudo"
    - name: Distribuera SSH-nyckel
      authorized_key:
        user: "{{ user }}"
        key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
        state: present

I det här fallet är konstruktionen intressant "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" — den kopierar innehållet i filen id_rsa.pub (du kanske har ett annat namn), det vill säga den offentliga delen av SSH-nyckeln och laddar upp den till listan över auktoriserade nycklar för användaren på servern.

Roller

Alla tre uppgifterna för att skapa användare kan lätt relateras till en grupp av uppgifter, och det skulle vara bra att lagra denna grupp separat från huvudplaybooken, så att den inte växer för mycket. För detta finns det i Ansible roller.
Enligt den filstruktur som angavs i början, måste roller placeras i en separat katalog som heter roles, varje roll får en egen katalog med ett liknande namn, inuti katalogen tasks, files, templates, etc.
Låt oss skapa filstrukturen: ./ansible/roles/user/tasks/main.yml (main — detta är huvudfilen som kommer att laddas och köras när rollen ansluts till playbooken, i den kan man ansluta andra roller). Nu kan vi flytta över alla uppgifter relaterade till användare till den här filen:

# Create user and add him to groups
- name: Ensure a 'sudo' group
  group:
    name: sudo
    state: present

- name: Add a new user
  user:
    name: "{{ user }}"
    shell: /bin/bash
    password: "{{ user_password | password_hash('sha512') }}"
    groups: "sudo"

- name: Deploy SSH Key
  authorized_key:
    user: "{{ user }}"
    key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
    state: present

I den huvudsakliga playbooken måste vi ange att rollen user ska användas:

---
- name: Enkel playbook
  hosts: all
  remote_user: root
  gather_facts: no

  tasks:
    - name: Uppdatera systemet
      apt: update_cache=yes
    - name: Installera systemberoenden
      apt:
        name: git,nginx,redis,postgresql,postgresql-contrib
        state: present

  roles:
    - user

Det kan också vara meningsfullt att utföra systemuppdateringar tidigare än de andra uppgifterna, för detta kan blocket som de är definierade i döpas om till tasks Nginx bör redan vara installerat, vi måste konfigurera det och starta det. Låt oss göra detta direkt i rollen. Vi skapar filstrukturen: pre_tasks.

Konfiguration av nginx

- ansible - roles - nginx - files - tasks - main.yml - templates

Nu behöver vi filer och mallar. Skillnaden mellan dem är att Ansible kopierar filer direkt, som de är. Mallar måste ha filändelsen j2 och kan använda värdena av variabler med hjälp av samma dubbla klamrar.

Låt oss inkludera nginx i

main.yml filen. För detta har vi systemd-modulen: Här säger vi inte bara att nginx ska startas (dvs vi startar det), utan vi säger också att det ska aktiveras.

# Copy nginx configs and start it
- name: enable service nginx and start
  systemd:
    name: nginx
    state: started
    enabled: yes

Så här anger vi att nginx ska startas (det vill säga vi kör det) och att det också ska aktiveras.
Nu kopierar vi konfigurationsfilerna:

# Copy nginx configs and start it
- name: enable service nginx and start
  systemd:
    name: nginx
    state: started
    enabled: yes

- name: Copy the nginx.conf
  copy:
    src: nginx.conf
    dest: /etc/nginx/nginx.conf
    owner: root
    group: root
    mode: '0644'
    backup: yes

- name: Copy template my_app.conf
  template:
    src: my_app_conf.j2
    dest: /etc/nginx/sites-available/my_app.conf
    owner: root
    group: root
    mode: '0644'

Vi skapar huvudkonfigurationsfilen för nginx (den kan tas direkt från servern eller skrivas av oss själva). Och även konfigurationsfilen för vår applikation i katalogen sites_available (detta är inte nödvändigt men användbart). I det första fallet använder vi modulen copy för att kopiera filer (filen måste ligga i /ansible/roles/nginx/files/nginx.conf). I det andra fallet kopierar vi en mall, där vi sätter in variabelvärden. Mallen måste ligga i /ansible/roles/nginx/templates/my_app.j2). Den kan se ut ungefär så här:

upstream {{ app_name }} {
  server unix:{{ app_path }}\/shared\/tmp\/sockets\/puma.sock;
}

server {
  listen 80;
  server_name {{ server_name }} {{ inventory_hostname }};
  root {{ app_path }}\/current\/public;

  try_files $uri\/index.html $uri.html $uri @{{ app_name }};
  ....
}

Observera insättningarna {{ app_name }}, {{ app_path }}, {{ server_name }}, {{ inventory_hostname }} — dessa är alla variabler vars värden ansible kommer att sätta in i mallen innan kopiering. Detta är användbart om du använder en spelbok för olika grupper av värdar. Till exempel kan vi komplettera vår inventory-fil:

[production]
123.123.123.123

[staging]
231.231.231.231

[all:vars]
user=my_user
user_password=123qweasd

[production:vars]
server_name=production
app_path=\/home\/www\/my_app
app_name=my_app

[staging:vars]
server_name=staging
app_path=\/home\/www\/my_stage
app_name=my_stage_app

Om vi nu kör vår spelbok, kommer den att utföra angivna uppgifter för båda värdarna. Men för staging-värden kommer variablerna att skilja sig från produktion, och inte bara i roller och spelböcker, utan även i nginx-konfigurationerna. {{ inventory_hostname }} det behöver inte anges i inventory-filen — detta är en speciell ansible-variabel och där lagras värden för den värd som spelboken för närvarande körs mot.
Om du vill ha en inventory-fil för flera värdar, men bara köra för en grupp, kan du göra detta med följande kommando:

ansible-playbook -i inventory .\/playbook.yml -l "staging"

ett annat alternativ — ha separata inventory-filer för olika grupper. Eller så kan du kombinera de två metoderna om du har många olika värdar.

Låt oss återgå till nginx-inställningarna. Efter att ha kopierat konfigurationsfilerna måste vi skapa en symbolisk länk i sites_enabled till my_app.conf från sites_available. Och starta om nginx.

... # gammal kod i mail.yml

- name: Skapa symbolisk länk till sites-enabled
  file:
    src: \/etc\/nginx\/sites-available\/my_app.conf
    dest: \/etc\/nginx\/sites-enabled\/my_app.conf
    state: link

- name: starta om nginx
  service:
    name: nginx
    state: restarted

Här är det enkelt — igen används ansible-moduler med en ganska standardiserad syntax. Men det finns en punkt att tänka på. Det är meningslöst att starta om nginx varje gång. Har du noterat att vi inte skriver kommandon av typen: "gör detta så här", syntaxen ser snarare ut som "detta ska ha ett sådant tillstånd". Och oftast är det just så ansible fungerar. Om gruppen redan finns, eller systempaketet redan är installerat, så kontrollerar ansible detta och hoppar över uppgiften. Filer kommer inte att kopieras om de är helt identiska med dem som redan finns på servern. Vi kan utnyttja detta och starta om nginx endast om konfigurationsfilerna har ändrats. För detta finns direktivet register:

# Copy nginx configs and start it
- name: enable service nginx and start
  systemd:
    name: nginx
    state: started
    enabled: yes

- name: Copy the nginx.conf
  copy:
    src: nginx.conf
    dest: /etc/nginx/nginx.conf
    owner: root
    group: root
    mode: '0644'
    backup: yes
  register: restart_nginx

- name: Copy template my_app.conf
  template:
    src: my_app_conf.j2
    dest: /etc/nginx/sites-available/my_app.conf
    owner: root
    group: root
    mode: '0644'
  register: restart_nginx

- name: Create symlink to sites-enabled
  file:
    src: /etc/nginx/sites-available/my_app.conf
    dest: /etc/nginx/sites-enabled/my_app.conf
    state: link

- name: restart nginx
  service:
    name: nginx
    state: restarted
  when: restart_nginx.changed

Om en av konfigurationsfilerna ändras, kommer kopiering att utföras och en variabel registreras restart_nginx. Och endast om den här variabeln har registrerats, kommer tjänsten att startas om.

Och så klart, vi måste lägga till rollen nginx i huvudplaybooken.

Konfiguration av postgresql

Vi behöver aktivera postgresql med hjälp av systemd på samma sätt som vi gjorde med nginx, och också skapa en användare som vi kommer att använda för att komma åt databasen och själva databasen.
Låt oss skapa en roll /ansible/roles/postgresql/tasks/main.yml:

# Create user in postgresql
- name: enable postgresql and start
  systemd:
    name: postgresql
    state: started
    enabled: yes

- name: Create database user
  become_user: postgres
  postgresql_user:
    name: "{{ db_user }}"
    password: "{{ db_password }}"
    role_attr_flags: SUPERUSER

- name: Create database
  become_user: postgres
  postgresql_db:
    name: "{{ db_name }}"
    encoding: UTF-8
    owner: "{{ db_user }}"

Jag kommer inte att beskriva hur man lägger till variabler i inventory, det har redan gjorts många gånger, likaså syntaxen för modulerna postgresql_db och postgresql_user. Mer information kan hittas i dokumentationen. Här är direktivet av mest intresse become_user: postgres. Faktum är att som standard har endast användaren postgres åtkomst till postgresql-databasen och endast lokalt. Detta direktiv låter oss köra kommandon i egenskap av denna användare (om vi så klart har åtkomst).
Det kan också hända att du måste lägga till en rad i pg_hba.conf för att öppna tillgången för den nya användaren till databasen. Detta kan göras på samma sätt som vi ändrade nginx-konfigurationsfilen.

Och självklart måste vi lägga till rollen postgresql i huvudplaybooken.

Installation av ruby via rbenv

Det finns inga ansible-moduler för att arbeta med rbenv, och det installeras genom att klona ett git-repository. Därför blir denna uppgift den mest otraditionella. Låt oss skapa en roll för den /ansible/roles/ruby_rbenv/main.yml och börja fylla den med innehåll:

# Install rbenv and ruby
- name: Install rbenv
  become_user: "{{ user }}"
  git: repo=https://github.com/rbenv/rbenv.git dest=~/.rbenv

Vi använder återigen direktivet become_user för att arbeta under den användare som vi har skapat för detta ändamål. Eftersom rbenv installeras i den användarens hemkatalog och inte globalt. Vi använder också git-modulen för att klona förvaret genom att ange repo och dest.

Därefter måste vi ange rbenv init i bashrc och även lägga till rbenv i PATH. För detta har vi modulen lineinfile:

- name: Lägg till rbenv i PATH
  become_user: "{{ user }}"
  lineinfile:
    path: ~\/.ashrc
    state: present
    line: 'export PATH="${HOME}\/.
benv\/bin:${PATH}"'

- name: Lägg till rbenv init i bashrc
  become_user: "{{ user }}"
  lineinfile:
    path: ~\/.ashrc
    state: present
    line: 'eval "$(rbenv init -)"'

Efter det måste vi installera ruby_build:

- name: Installera ruby-build
  become_user: "{{ user }}"
  git: repo=https:\/\/github.com\/rbenv\/ruby-build.git dest=~\/.
benv\/plugins\/ruby-build

Och slutligen installera ruby. Detta görs via rbenv, alltså med ett enkelt bash-kommando:

- name: Installera ruby
  become_user: "{{ user }}"
  shell: |
    export PATH="${HOME}\/.
benv\/bin:${PATH}"
    eval "$(rbenv init -)"
    rbenv install {{ ruby_version }}
  args:
    executable: \/bin\/bash

Vi anger vilken kommando som ska köras och hur. Men här stöter vi på att ansible inte kör koden som finns i bashrc innan kommandona körs. Det betyder att rbenv måste definieras direkt i detta skript.

Nästa problem är att shell-kommandot inte har något tillstånd ur ansibles perspektiv. Det finns ingen automatisk kontroll av om denna version av ruby är installerad eller inte — detta måste vi göra själva:

- name: Installera ruby
  become_user: "{{ user }}"
  shell: |
    export PATH="${HOME}\/.
benv\/bin:${PATH}"
    eval "$(rbenv init -)"
    if ! rbenv versions | grep -q {{ ruby_version }}
      then rbenv install {{ ruby_version }} && rbenv global {{ ruby_version }}
    fi
  args:
    executable: \/bin\/bash

Och vi måste installera bundler:

- name: Installera bundler
  become_user: "{{ user }}"
  shell: |
    export PATH="${HOME}\/.
benv\/bin:${PATH}"
    eval "$(rbenv init -)"
    gem install bundler

Och återigen lägga till vår roll ruby_rbenv i huvudplaybooken.

Dela filer.

Sammanfattningsvis skulle inställningen kunna avslutas här. Nästa steg är att köra capistrano och det kommer automatiskt att kopiera koden, skapa nödvändiga kataloger och starta applikationen (om allt är korrekt konfigurerat). Men ofta behöver capistrano ytterligare konfigurationsfiler, såsom database.yml eller .env Dessa kan kopieras precis som filer och mallar för nginx. Det finns bara en liten detalj. Innan vi kopierar filerna måste vi skapa katalogstrukturen för dem, något i stil med detta:

# Copy shared files for deploy
- name: Ensure shared dir
  become_user: "{{ user }}"
  file:
    path: "{{ app_path }}/shared/config"
    state: directory

Vi anger bara en katalog och ansible skapar automatiskt föräldrakatalogerna om det behövs.

Ansible Vault

Vi har redan stött på att det kan finnas känsliga uppgifter som användarlösenord i variabler. Om du har skapat .env en fil för applikationen, och database.yml så bör det finnas ännu fler sådana kritiska uppgifter där. Dessa bör du hålla gömda för obehöriga. För detta används ansible vault.

Låt oss skapa en fil för variabler /ansible/vars/all.yml (här kan du skapa olika filer för olika grupper av värdar, precis som i inventory-filen: production.yml, staging.yml, osv.).
I denna fil måste du överföra alla variabler som ska krypteras, med hjälp av standard yml-syntax:

# System vars
user_password: 123qweasd
db_password: 123qweasd

# ENV vars
aws_access_key_id: xxxxx
aws_secret_access_key: xxxxxx
aws_bucket: bucket_name
rails_secret_key_base: very_secret_key_base

Därefter kan du kryptera denna fil med kommandot:

ansible-vault encrypt .\/vars\/all.yml

Naturligtvis måste du ange ett lösenord för dekryptering vid kryptering. Du kan se vad som kommer att finnas i filen efter att ha kört detta kommando.

Med hjälp av ansible-vault decrypt filen kan dekrypteras, ändras och sedan krypteras igen.

För att arbeta behöver du inte dekryptera filen. Du lagrar den i krypterad form och kör playbook med argumentet --ask-vault-pass. Ansible kommer att fråga efter lösenordet, hämta variablerna och utföra uppgifterna. All data förblir krypterad.

Den fullständiga kommandot för flera grupper av värdar och ansible vault kommer att se ut ungefär så här:

ansible-playbook -i inventory .\/playbook.yml -l "staging" --ask-vault-pass

Och jag kommer inte att ge dig hela texten av playbooks och roller, skriv själv. För ansible är så, om du inte förstår vad som behöver göras, så kommer det inte att göra det.

Källa: habr.com