ProHoster > Օրագիր > Վարչակազմը > Nomad կլաստերի ստեղծում՝ օգտագործելով Consul-ը և ինտեգրվելով Gitlab-ին

Nomad կլաստերի ստեղծում՝ օգտագործելով Consul-ը և ինտեգրվելով Gitlab-ին

Ներածություն

Վերջերս Kubernetes-ի ժողովրդականությունը արագորեն աճում է. ավելի ու ավելի շատ նախագծեր են այն իրականացնում: Ես ուզում էի անդրադառնալ Nomad-ի պես նվագախմբին. այն կատարյալ է նախագծերի համար, որոնք արդեն օգտագործում են HashiCorp-ի այլ լուծումներ, օրինակ՝ Vault-ը և Consul-ը, և նախագծերն իրենք բարդ չեն ենթակառուցվածքի առումով: Այս նյութը պարունակում է հրահանգներ Nomad-ի տեղադրման, երկու հանգույցների կլաստերի մեջ միավորելու, ինչպես նաև Nomad-ի Gitlab-ի հետ ինտեգրման համար։

Nomad կլաստերի ստեղծում՝ օգտագործելով Consul-ը և ինտեգրվելով Gitlab-ին

Փորձարկման տակդիր

Մի փոքր թեստային նստարանի մասին. երեք վիրտուալ սերվերներ օգտագործվում են 2 CPU, 4 RAM, 50 Gb SSD, միավորված ընդհանուր տեղական ցանցի բնութագրերով: Նրանց անունները և IP հասցեները.

  1. nomad-livelinux-01: 172.30.0.5
  2. nomad-livelinux-02: 172.30.0.10
  3. consul-livelinux-01: 172.30.0.15

Nomad-ի տեղադրում, հյուպատոս. Քոչվորների կլաստերի ստեղծում

Սկսենք հիմնական տեղադրումից: Թեև կարգավորումը պարզ էր, ես այն նկարագրելու եմ հանուն հոդվածի ամբողջականության. այն ըստ էության ստեղծվել է նախագծերից և նշումներից՝ անհրաժեշտության դեպքում արագ մուտք գործելու համար:

Նախքան պրակտիկան սկսելը, մենք կքննարկենք տեսական մասը, քանի որ այս փուլում կարևոր է հասկանալ ապագա կառուցվածքը:

Մենք ունենք երկու քոչվոր հանգույց և ցանկանում ենք դրանք միավորել կլաստերի մեջ, իսկ ապագայում մեզ անհրաժեշտ կլինի նաև ավտոմատ կլաստերային մասշտաբավորում. դրա համար մեզ անհրաժեշտ կլինի հյուպատոս: Այս գործիքի միջոցով կլաստերավորումը և նոր հանգույցների ավելացումը դառնում է շատ պարզ խնդիր՝ ստեղծված Nomad հանգույցը միանում է Consul գործակալին, այնուհետև միանում է գոյություն ունեցող Nomad կլաստերին։ Հետևաբար, սկզբում մենք կտեղադրենք Consul սերվերը, կկազմաձևենք հիմնական http թույլտվությունը վեբ վահանակի համար (այն առանց թույլտվության է լռելյայն և կարելի է մուտք գործել արտաքին հասցեով), ինչպես նաև իրենք՝ Consul գործակալները Nomad սերվերների վրա, որից հետո մենք միայն կշարունակենք դեպի Nomad.

HashiCorp-ի գործիքների տեղադրումը շատ պարզ է. ըստ էության, մենք պարզապես տեղափոխում ենք երկուական ֆայլը աղբարկղ, կարգավորում գործիքի կազմաձևման ֆայլը և ստեղծում դրա սպասարկման ֆայլը:

Ներբեռնեք Consul երկուական ֆայլը և բացեք այն օգտագործողի տնային գրացուցակում.

root@consul-livelinux-01:~# wget https://releases.hashicorp.com/consul/1.5.0/consul_1.5.0_linux_amd64.zip
root@consul-livelinux-01:~# unzip consul_1.5.0_linux_amd64.zip
root@consul-livelinux-01:~# mv consul /usr/local/bin/

Այժմ մենք ունենք պատրաստի հյուպատոսական երկուական՝ հետագա կազմաձևման համար:

Հյուպատոսի հետ աշխատելու համար մենք պետք է ստեղծենք եզակի բանալի՝ օգտագործելով keygen հրամանը.

root@consul-livelinux-01:~# consul keygen

Եկեք անցնենք Consul-ի կոնֆիգուրացիան կարգավորելուն՝ ստեղծելով /etc/consul.d/ գրացուցակ հետևյալ կառուցվածքով.

/etc/consul.d/
├── bootstrap
│   └── config.json

Bootstrap գրացուցակը կպարունակի կոնֆիգուրացիայի ֆայլ config.json - դրանում մենք կսահմանենք Consul-ի կարգավորումները: Դրա բովանդակությունը.

{
"bootstrap": true,
"server": true,
"datacenter": "dc1",
"data_dir": "/var/consul",
"encrypt": "your-key",
"log_level": "INFO",
"enable_syslog": true,
"start_join": ["172.30.0.15"]
}

Եկեք առանձին նայենք հիմնական հրահանգներին և դրանց իմաստներին.

  • bootstrap: ճիշտ. Մենք միացնում ենք նոր հանգույցների ավտոմատ ավելացումը, եթե դրանք միացված են: Ես նշում եմ, որ մենք այստեղ չենք նշում ակնկալվող հանգույցների ճշգրիտ թիվը:
  • սերվեր: ճիշտ. Միացնել սերվերի ռեժիմը: Այս վիրտուալ մեքենայի հյուպատոսը հանդես կգա որպես միակ սերվեր և վարպետ այս պահին, Nomad's VM-ը կլինի հաճախորդները:
  • datacenter- ըdc1. Նշեք տվյալների կենտրոնի անունը՝ կլաստերը ստեղծելու համար: Այն պետք է նույնական լինի ինչպես հաճախորդների, այնպես էլ սերվերների վրա:
  • encrypt: Ձեր բանալին: Բանալին, որը նույնպես պետք է լինի եզակի և համապատասխանի բոլոր հաճախորդներին և սերվերներին: Ստեղծվել է consul keygen հրամանի միջոցով:
  • start_join. Այս ցանկում մենք նշում ենք IP հասցեների ցանկը, որոնց հետ կապը կկատարվի: Այս պահին մենք թողնում ենք միայն մեր սեփական հասցեն։

Այս պահին մենք կարող ենք հյուպատոս գործարկել՝ օգտագործելով հրամանի տողը.

root@consul-livelinux-01:~# /usr/local/bin/consul agent -config-dir /etc/consul.d/bootstrap -ui

Սա այժմ վրիպազերծելու լավ միջոց է, սակայն, ակնհայտ պատճառներով դուք չեք կարողանա շարունակաբար օգտագործել այս մեթոդը: Եկեք ստեղծենք ծառայության ֆայլ՝ հյուպատոսին systemd-ի միջոցով կառավարելու համար.

root@consul-livelinux-01:~# nano /etc/systemd/system/consul.service

Consul.service ֆայլի բովանդակությունը. 

[Unit]
Description=Consul Startup process
After=network.target
 
[Service]
Type=simple
ExecStart=/bin/bash -c '/usr/local/bin/consul agent -config-dir /etc/consul.d/bootstrap -ui' 
TimeoutStartSec=0
 
[Install]
WantedBy=default.target

Գործարկել հյուպատոսը systemctl-ի միջոցով.

root@consul-livelinux-01:~# systemctl start consul

Եկեք ստուգենք. մեր ծառայությունը պետք է աշխատի, և հյուպատոսի անդամների հրամանը կատարելով մենք պետք է տեսնենք մեր սերվերը.

root@consul-livelinux:/etc/consul.d# consul members
consul-livelinux    172.30.0.15:8301  alive   server  1.5.0  2         dc1  <all>

Հաջորդ փուլը՝ Nginx-ի տեղադրում և պրոքսի և http թույլտվության կարգավորում: Մենք տեղադրում ենք nginx փաթեթի կառավարչի միջոցով և /etc/nginx/sites-enabled գրացուցակում ստեղծում ենք consul.conf կոնֆիգուրացիայի ֆայլ հետևյալ բովանդակությամբ.

upstream consul-auth {
    server localhost:8500;
}

server {

    server_name consul.doman.name;
    
    location / {
      proxy_pass http://consul-auth;
      proxy_set_header Host $host;
      auth_basic_user_file /etc/nginx/.htpasswd;
      auth_basic "Password-protected Area";
    }
}

Մի մոռացեք ստեղծել .htpasswd ֆայլ և դրա համար ստեղծել օգտանուն և գաղտնաբառ: Այս տարրը պարտադիր է, որպեսզի վեբ վահանակը հասանելի չլինի բոլորին, ովքեր գիտեն մեր տիրույթը: Այնուամենայնիվ, Gitlab-ը կարգավորելիս մենք ստիպված կլինենք հրաժարվել դրանից, հակառակ դեպքում մենք չենք կարողանա մեր հավելվածը տեղակայել Nomad-ում: Իմ նախագծում և՛ Gitlab-ը, և՛ Nomad-ը միայն գորշ ցանցում են, ուստի այստեղ նման խնդիր չկա։

Մնացած երկու սերվերների վրա մենք տեղադրում ենք Consul agents՝ համաձայն հետևյալ հրահանգների: Երկուական ֆայլով մենք կրկնում ենք քայլերը.

root@nomad-livelinux-01:~# wget https://releases.hashicorp.com/consul/1.5.0/consul_1.5.0_linux_amd64.zip
root@nomad-livelinux-01:~# unzip consul_1.5.0_linux_amd64.zip
root@nomad-livelinux-01:~# mv consul /usr/local/bin/

Նախորդ սերվերի անալոգիայով մենք ստեղծում ենք կազմաձևման ֆայլերի /etc/consul.d գրացուցակ հետևյալ կառուցվածքով.

/etc/consul.d/
├── client
│   └── config.json

config.json ֆայլի բովանդակությունը.

{
    "datacenter": "dc1",
    "data_dir": "/opt/consul",
    "log_level": "DEBUG",
    "node_name": "nomad-livelinux-01",
    "server": false,
    "encrypt": "your-private-key",
    "domain": "livelinux",
    "addresses": {
      "dns": "127.0.0.1",
      "https": "0.0.0.0",
      "grpc": "127.0.0.1",
      "http": "127.0.0.1"
    },
    "bind_addr": "172.30.0.5", # локальный адрес вм
    "start_join": ["172.30.0.15"], # удаленный адрес консул сервера
    "ports": {
      "dns": 53
     }

Պահպանեք փոփոխությունները և անցեք ծառայության ֆայլի, դրա բովանդակության կարգավորումներին.

/etc/systemd/system/consul.service:

[Unit]
Description="HashiCorp Consul - A service mesh solution"
Documentation=https://www.consul.io/
Requires=network-online.target
After=network-online.target

[Service]
User=root
Group=root
ExecStart=/usr/local/bin/consul agent -config-dir=/etc/consul.d/client
ExecReload=/usr/local/bin/consul reload
KillMode=process
Restart=on-failure

[Install]
WantedBy=multi-user.target

Մենք գործարկում ենք հյուպատոս սերվերի վրա: Այժմ, գործարկումից հետո, մենք պետք է տեսնենք կազմաձևված ծառայությունը nsul անդամների մեջ: Սա կնշանակի, որ այն հաջողությամբ միացել է կլաստերին որպես հաճախորդ: Նույնը կրկնեք երկրորդ սերվերի վրա, և դրանից հետո մենք կարող ենք սկսել Nomad-ի տեղադրումն ու կազմաձևումը:

Nomad-ի ավելի մանրամասն տեղադրումը նկարագրված է նրա պաշտոնական փաստաթղթերում: Տեղադրման երկու ավանդական եղանակ կա՝ երկուական ֆայլի ներբեռնում և աղբյուրից հավաքում: Ես կընտրեմ առաջին մեթոդը.

ՆշումՆախագիծը շատ արագ է զարգանում, հաճախ են թողարկվում նոր թարմացումներ։ Հավանաբար, նոր տարբերակ կթողարկվի մինչև այս հոդվածը ավարտվի: Հետևաբար, կարդալուց առաջ խորհուրդ եմ տալիս ստուգել Nomad-ի ընթացիկ տարբերակը և ներբեռնել այն։ 

root@nomad-livelinux-01:~# wget https://releases.hashicorp.com/nomad/0.9.1/nomad_0.9.1_linux_amd64.zip
root@nomad-livelinux-01:~# unzip nomad_0.9.1_linux_amd64.zip
root@nomad-livelinux-01:~# mv nomad /usr/local/bin/
root@nomad-livelinux-01:~# nomad -autocomplete-install
root@nomad-livelinux-01:~# complete -C /usr/local/bin/nomad nomad
root@nomad-livelinux-01:~# mkdir /etc/nomad.d

Փաթեթավորումից հետո մենք կստանանք Nomad երկուական ֆայլ՝ 65 ՄԲ քաշով, այն պետք է տեղափոխվի /usr/local/bin:

Եկեք Nomad-ի համար ստեղծենք տվյալների գրացուցակ և խմբագրենք դրա սպասարկման ֆայլը (այն ամենայն հավանականությամբ սկզբում գոյություն չի ունենա).

root@nomad-livelinux-01:~# mkdir --parents /opt/nomad
root@nomad-livelinux-01:~# nano /etc/systemd/system/nomad.service

Այնտեղ տեղադրեք հետևյալ տողերը.

[Unit]
Description=Nomad
Documentation=https://nomadproject.io/docs/
Wants=network-online.target
After=network-online.target

[Service]
ExecReload=/bin/kill -HUP $MAINPID
ExecStart=/usr/local/bin/nomad agent -config /etc/nomad.d
KillMode=process
KillSignal=SIGINT
LimitNOFILE=infinity
LimitNPROC=infinity
Restart=on-failure
RestartSec=2
StartLimitBurst=3
StartLimitIntervalSec=10
TasksMax=infinity

[Install]
WantedBy=multi-user.target

Այնուամենայնիվ, մենք չենք շտապում գործարկել nomad-ը, մենք դեռ չենք ստեղծել դրա կազմաձևման ֆայլը.

root@nomad-livelinux-01:~# mkdir --parents /etc/nomad.d
root@nomad-livelinux-01:~# chmod 700 /etc/nomad.d
root@nomad-livelinux-01:~# nano /etc/nomad.d/nomad.hcl
root@nomad-livelinux-01:~# nano /etc/nomad.d/server.hcl

Գրացուցակի վերջնական կառուցվածքը կլինի հետևյալը.

/etc/nomad.d/
├── nomad.hcl
└── server.hcl

Nomad.hcl ֆայլը պետք է պարունակի հետևյալ կոնֆիգուրացիան.

datacenter = "dc1"
data_dir = "/opt/nomad"

Server.hcl ֆայլի բովանդակությունը.

server {
  enabled = true
  bootstrap_expect = 1
}

consul {
  address             = "127.0.0.1:8500"
  server_service_name = "nomad"
  client_service_name = "nomad-client"
  auto_advertise      = true
  server_auto_join    = true
  client_auto_join    = true
}

bind_addr = "127.0.0.1" 

advertise {
  http = "172.30.0.5"
}

client {
  enabled = true
}

Մի մոռացեք փոխել կազմաձևման ֆայլը երկրորդ սերվերի վրա. այնտեղ դուք պետք է փոխեք http հրահանգի արժեքը:

Այս փուլում վերջին բանը Nginx-ը կարգավորելն է պրոքսինգի և http թույլտվությունը կարգավորելու համար: Nomad.conf ֆայլի բովանդակությունը.

upstream nomad-auth {
        server 172.30.0.5:4646;
}

server {

        server_name nomad.domain.name;
        
        location / {
	        proxy_pass http://nomad-auth;
	        proxy_set_header Host $host;
	        auth_basic_user_file /etc/nginx/.htpasswd;
		   auth_basic "Password-protected Area";
        }
        
}

Այժմ մենք կարող ենք մուտք գործել վեբ վահանակ արտաքին ցանցի միջոցով: Միացեք և անցեք սերվերների էջ.

Nomad կլաստերի ստեղծում՝ օգտագործելով Consul-ը և ինտեգրվելով Gitlab-ին
Պատկեր 1. Nomad կլաստերի սերվերների ցուցակ

Երկու սերվերները հաջողությամբ ցուցադրվում են վահանակում, մենք նույն բանը կտեսնենք քոչվոր հանգույցի կարգավիճակի հրամանի ելքում.

Nomad կլաստերի ստեղծում՝ օգտագործելով Consul-ը և ինտեգրվելով Gitlab-ին
Պատկեր 2. Քոչվոր հանգույցի կարգավիճակի հրամանի ելք

Ինչ վերաբերում է հյուպատոսին: Եկեք նայենք: Գնացեք հյուպատոսի կառավարման վահանակ, հանգույցների էջ.
Nomad կլաստերի ստեղծում՝ օգտագործելով Consul-ը և ինտեգրվելով Gitlab-ին
Պատկեր 3. Հյուպատոսների կլաստերի հանգույցների ցանկը

Այժմ մենք ունենք պատրաստված Nomad-ը, որը աշխատում է հյուպատոսի հետ համատեղ: Վերջնական փուլում մենք կհասնենք զվարճալի մասին՝ տեղադրելով Docker կոնտեյներների առաքում Gitlab-ից Nomad, ինչպես նաև խոսել դրա որոշ այլ տարբերակիչ հատկանիշների մասին:

Gitlab Runner-ի ստեղծում

Docker պատկերները Nomad-ում տեղակայելու համար մենք կօգտագործենք առանձին վազող՝ ներսում Nomad երկուական ֆայլով (այստեղ, ի դեպ, կարող ենք նշել Hashicorp հավելվածների մեկ այլ առանձնահատկություն. առանձին-առանձին դրանք մեկ երկուական ֆայլ են): Վերբեռնեք այն runner գրացուցակում: Եկեք դրա համար ստեղծենք պարզ Dockerfile հետևյալ բովանդակությամբ.


FROM alpine:3.9
RUN apk add --update --no-cache libc6-compat gettext
COPY nomad /usr/local/bin/nomad

Նույն նախագծում մենք ստեղծում ենք .gitlab-ci.yml:

variables:
  DOCKER_IMAGE: nomad/nomad-deploy
  DOCKER_REGISTRY: registry.domain.name
 

stages:
  - build

build:
  stage: build
  image: ${DOCKER_REGISTRY}/nomad/alpine:3
  script:
    - tag=${DOCKER_REGISTRY}/${DOCKER_IMAGE}:latest
    - docker build --pull -t ${tag} -f Dockerfile .
    - docker push ${tag}

Արդյունքում, մենք կունենանք Nomad-ի վազորդի հասանելի պատկերը Gitlab ռեգիստրում, այժմ մենք կարող ենք ուղղակիորեն գնալ նախագծի պահեստ, ստեղծել Pipeline և կարգավորել Nomad-ի քոչվոր աշխատանքը:

Ծրագրի կարգավորում

Սկսենք Nomad-ի աշխատանքի ֆայլից: Այս հոդվածում իմ նախագիծը բավականին պարզունակ կլինի. այն բաղկացած կլինի մեկ առաջադրանքից. .gitlab-ci-ի բովանդակությունը կլինի հետևյալը.

variables:
  NOMAD_ADDR: http://nomad.address.service:4646
  DOCKER_REGISTRY: registry.domain.name
  DOCKER_IMAGE: example/project

stages:
  - build
  - deploy

build:
  stage: build
  image: ${DOCKER_REGISTRY}/nomad-runner/alpine:3
  script:
    - tag=${DOCKER_REGISTRY}/${DOCKER_IMAGE}:${CI_COMMIT_SHORT_SHA}
    - docker build --pull -t ${tag} -f Dockerfile .
    - docker push ${tag}


deploy:
  stage: deploy
  image: registry.example.com/nomad/nomad-runner:latest
  script:
    - envsubst '${CI_COMMIT_SHORT_SHA}' < project.nomad > job.nomad
    - cat job.nomad
    - nomad validate job.nomad
    - nomad plan job.nomad || if [ $? -eq 255 ]; then exit 255; else echo "success"; fi
    - nomad run job.nomad
  environment:
    name: production
  allow_failure: false
  when: manual

Այստեղ տեղակայումը տեղի է ունենում ձեռքով, բայց դուք կարող եք կարգավորել այն՝ փոխելու նախագծի գրացուցակի բովանդակությունը: Խողովակաշարը բաղկացած է երկու փուլից՝ պատկերի հավաքում և տեղակայում քոչվորում: Առաջին փուլում մենք հավաքում ենք դոկերի պատկերը և այն մղում մեր ռեգիստր, իսկ երկրորդում մենք սկսում ենք մեր աշխատանքը Nomad-ում: 

job "monitoring-status" {
    datacenters = ["dc1"]
    migrate {
        max_parallel = 3
        health_check = "checks"
        min_healthy_time = "15s"
        healthy_deadline = "5m"
    }

    group "zhadan.ltd" {
        count = 1
        update {
            max_parallel      = 1
            min_healthy_time  = "30s"
            healthy_deadline  = "5m"
            progress_deadline = "10m"
            auto_revert       = true
        }
        task "service-monitoring" {
            driver = "docker"

            config {
                image = "registry.domain.name/example/project:${CI_COMMIT_SHORT_SHA}"
                force_pull = true
                auth {
                    username = "gitlab_user"
                    password = "gitlab_password"
                }
                port_map {
                    http = 8000
                }
            }
            resources {
                network {
                    port "http" {}
                }
            }
        }
    }
}

Խնդրում ենք նկատի ունենալ, որ ես ունեմ մասնավոր ռեգիստր, և դոկերի պատկերը հաջողությամբ հանելու համար պետք է մուտք գործեմ այնտեղ: Այս դեպքում լավագույն լուծումը մուտքի և գաղտնաբառի մուտքագրումն է Vault-ում, այնուհետև այն ինտեգրելը Nomad-ի հետ: Nomad-ը բնիկորեն աջակցում է Vault-ին: Բայց նախ, եկեք տեղադրենք Nomad-ի համար անհրաժեշտ քաղաքականությունները հենց Vault-ում, դրանք կարելի է ներբեռնել.

# Download the policy and token role
$ curl https://nomadproject.io/data/vault/nomad-server-policy.hcl -O -s -L
$ curl https://nomadproject.io/data/vault/nomad-cluster-role.json -O -s -L

# Write the policy to Vault
$ vault policy write nomad-server nomad-server-policy.hcl

# Create the token role with Vault
$ vault write /auth/token/roles/nomad-cluster @nomad-cluster-role.json

Այժմ, ստեղծելով անհրաժեշտ քաղաքականությունները, մենք կավելացնենք Vault-ի հետ ինտեգրումը job.nomad ֆայլի առաջադրանքների բլոկում.

vault {
  enabled = true
  address = "https://vault.domain.name:8200"
  token = "token"
}

Ես օգտագործում եմ թույլտվությունը նշանով և գրանցում եմ այն ​​անմիջապես այստեղ, կա նաև քոչվոր գործակալը սկսելիս նշանը որպես փոփոխական նշելու տարբերակը.

$ VAULT_TOKEN=<token> nomad agent -config /path/to/config

Այժմ մենք կարող ենք օգտագործել ստեղները Vault-ով: Գործողության սկզբունքը պարզ է. Nomad job-ում ստեղծում ենք ֆայլ, որը կպահի փոփոխականների արժեքները, օրինակ.

template {
                data = <<EOH
{{with secret "secrets/pipeline-keys"}}
REGISTRY_LOGIN="{{ .Data.REGISTRY_LOGIN }}"
REGISTRY_PASSWORD="{{ .Data.REGISTRY_LOGIN }}{{ end }}"

EOH
    destination = "secrets/service-name.env"
    env = true
}

Այս պարզ մոտեցմամբ դուք կարող եք կարգավորել բեռնարկղերի առաքումը Nomad կլաստերին և աշխատել դրա հետ ապագայում: Ես կասեմ, որ ինչ-որ չափով ես համակրում եմ Nomad-ին. այն ավելի հարմար է փոքր նախագծերի համար, որտեղ Kubernetes-ը կարող է լրացուցիչ բարդություն առաջացնել և չի իրացնի իր ողջ ներուժը: Բացի այդ, Nomad-ը կատարյալ է սկսնակների համար. այն հեշտ է տեղադրել և կարգավորել: Այնուամենայնիվ, որոշ նախագծերի վրա փորձարկելիս ես բախվում եմ դրա վաղ տարբերակների հետ կապված խնդրի հետ. շատ հիմնական գործառույթներ պարզապես չկան կամ ճիշտ չեն աշխատում: Այնուամենայնիվ, կարծում եմ, որ Nomad-ը կշարունակի զարգանալ և ապագայում ձեռք կբերի այն գործառույթները, որոնք անհրաժեշտ են բոլորին։

Հեղինակ՝ Իլյա Անդրեև, խմբագրվել է Ալեքսեյ Ժադանի և Live Linux թիմի կողմից


Source: www.habr.com

Добавить комментарий