ProHoster > Docker padomi: iztīriet savu ierīci no nevēlamā

Docker padomi: iztīriet savu ierīci no nevēlamā

Docker padomi: iztīriet savu ierīci no nevēlamā

Čau Habr! Piedāvāju jÅ«su uzmanÄ«bai raksta tulkojumu "Dokera padomi: notÄ«riet savu vietējo maŔīnu" autors LÅ«ks Džudžerijs.

Å odien mēs runāsim par to, kā Docker izmanto saimniekdatora diska vietu, kā arÄ« izdomāsim, kā atbrÄ«vot Å”o vietu no neizmantoto attēlu un konteineru lūžņiem.


Docker padomi: iztīriet savu ierīci no nevēlamā

Kopējais patēriņŔ

Docker ir forÅ”a lieta, droÅ”i vien daži cilvēki Å”odien par to Å”aubās. Tikai pirms dažiem gadiem Å”is produkts mums sniedza pilnÄ«gi jaunu veidu, kā veidot, piegādāt un darbināt jebkuru vidi, ļaujot ievērojami ietaupÄ«t CPU un RAM resursus. Papildus tam (un dažiem tas bÅ«s vissvarÄ«gākais) Docker ir ļāvis mums neticami vienkārÅ”ot un apvienot mÅ«su ražoÅ”anas vides dzÄ«ves cikla pārvaldÄ«bu.

Tomēr visiem Å”iem mÅ«sdienu dzÄ«ves priekiem ir sava cena. Kad mēs darbinām konteinerus, lejupielādējam vai veidojam savus attēlus un izvietojam sarežģītas ekosistēmas, mums ir jāmaksā. Un mēs maksājam, cita starpā, ar vietu diskā.

Ja jÅ«s nekad neesat domājis par to, cik daudz vietas Docker patiesÄ«bā aizņem jÅ«su datorā, jÅ«s varētu bÅ«t nepatÄ«kami pārsteigts par Ŕīs komandas izvadi:

$ docker system df

Docker padomi: iztīriet savu ierīci no nevēlamā

Tas parāda Docker diska lietojumu dažādos kontekstos:

  • attēli ā€“ kopējais attēlu lielums, kas tika lejupielādēti no attēlu krātuvēm un tika izveidoti jÅ«su sistēmā;
  • konteineri ā€“ kopējais diska vietas apjoms, ko izmanto darbināmie konteineri (ar to saprotot visu konteineru kopējo lasÄ«Å”anas un rakstÄ«Å”anas slāņu apjomu);
  • lokālie apjomi ā€“ konteineriem piemontētās vietējās noliktavas apjoms;
  • veidot keÅ”atmiņu ā€“ pagaidu faili, kas Ä£enerēti attēlu veidoÅ”anas procesā (izmantojot rÄ«ku BuildKit, kas pieejams sākot ar Docker versiju 18.09).

Varu derēt, ka pēc Ŕīs vienkārŔās pārsÅ«tÄ«Å”anas jÅ«s vēlēsities iztÄ«rÄ«t disku no atkritumiem un atdzÄ«vināt vērtÄ«gos gigabaitus (piezÄ«me: Ä«paÅ”i, ja par Å”iem gigabaitiem maksājat Ä«ri katru mēnesi).

Diska izmantoŔana konteineros

Katru reizi, kad resursdatorā izveidojat konteineru, direktorijā /var/lib/docker tiek izveidoti vairāki faili un direktoriji, starp kuriem ir vērts atzīmēt:

  • Direktorijs /var/lib/docker/containers/container_ID ā€” izmantojot standarta reÄ£istrÄ“Å”anas draiveri, notikumu žurnāli tiek saglabāti JSON formātā. Pārāk detalizēti žurnāli, kā arÄ« žurnāli, kurus neviens nelasa vai citādi neapstrādā, bieži izraisa disku pilnÄ«bu.
  • Direktorijā /var/lib/docker/overlay2 ir konteinera lasÄ«Å”anas un rakstÄ«Å”anas slāņi (overlay2 ir vēlamais draiveris lielākajā daļā Linux izplatÄ«jumu). Ja konteiners saglabā datus savā failu sistēmā, tad tas tiks ievietots Å”ajā direktorijā.

Iedomāsimies sistēmu, kurā ir uzstādÄ«ts senatnÄ«gs Docker, kas nekad nav bijis iesaistÄ«ts konteineru palaiÅ”anā vai attēlu veidoÅ”anā. Tās diska vietas izmantoÅ”anas pārskats izskatÄ«sies Ŕādi:

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         0          0          0B         0B
Containers     0          0          0B         0B
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

Palaidīsim kādu konteineru, piemēram, NGINX:

$ docker container run --name www -d -p 8000:80 nginx:1.16

Kas notiek ar disku:

  • attēli aizņem 126 MB, tas ir tas pats NGINX, ko mēs palaižām konteinerā;
  • konteineri aizņem smieklÄ«gus 2 baitus.

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         1          1          126M       0B (0%)
Containers     1          1          2B         0B (0%)
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

Spriežot pēc secinājuma, mums vēl nav vietas, ko mēs varētu atbrÄ«vot. Tā kā 2 baiti ir pilnÄ«gi vieglprātÄ«gi, iedomāsimies, ka mÅ«su NGINX negaidÄ«ti ierakstÄ«ja kaut kur 100 megabaitus datu un izveidoja tieÅ”i Ŕāda izmēra failu test.img sevÄ«.

$ docker exec -ti www 
  dd if=/dev/zero of=test.img bs=1024 count=0 seek=$[1024*100]

Vēlreiz pārbaudÄ«sim resursdatora diska vietas izmantoÅ”anu. Mēs redzēsim, ka konteiners (konteineri) tur aizņem 100 megabaitus.

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         1          1          126M       0B (0%)
Containers     1          1          104.9MB    0B (0%)
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

Es domāju, ka jūsu zinātkārās smadzenes jau prāto, kur atrodas mūsu test.img fails. Meklēsim to:

$ find /var/lib/docker -type f -name test.img
/var/lib/docker/overlay2/83f177...630078/merged/test.img
/var/lib/docker/overlay2/83f177...630078/diff/test.img

Neiedziļinoties detaļās, varam atzÄ«mēt, ka fails test.img ir ērti izvietots lasÄ«Å”anas-rakstÄ«Å”anas lÄ«menÄ«, ko kontrolē overlay2 draiveris. Ja mēs apturēsim savu konteineru, saimnieks mums pateiks, ka Å”o vietu principā var atbrÄ«vot:

# Stopping the www container
$ docker stop www

# Visualizing the impact on the disk usage
$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         1          1          126M       0B (0%)
Containers     1          0          104.9MB    104.9MB (100%)
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

Kā mēs to varam izdarÄ«t? DzÄ“Å”ot konteineru, kas nozÄ«mēs atbilstoŔās vietas notÄ«rÄ«Å”anu lasÄ«Å”anas un rakstÄ«Å”anas lÄ«menÄ«.

Izmantojot Å”o komandu, varat vienā rāvienā noņemt visus instalētos konteinerus un notÄ«rÄ«t disku no visiem to izveidotajiem lasÄ«Å”anas un rakstÄ«Å”anas failiem:

$ docker container prune
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y
Deleted Containers:
5e7f8e5097ace9ef5518ebf0c6fc2062ff024efb495f11ccc89df21ec9b4dcc2

Total reclaimed space: 104.9MB

Tātad, izdzÄ“Å”ot konteineru, mēs atbrÄ«vojām 104,9 megabaitus. Bet, tā kā mēs vairs neizmantojam iepriekÅ” lejupielādēto attēlu, tas arÄ« kļūst par kandidātu mÅ«su resursu dzÄ“Å”anai un atbrÄ«voÅ”anai:

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         1          0          126M       126M (100%)
Containers     0          0          0B         0B
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

PiezÄ«me. Kamēr attēlu izmantos vismaz viens konteiners, jÅ«s nevarēsit izmantot Å”o triku.

IepriekÅ” izmantotā plÅ«mju apakÅ”komanda ietekmē tikai apturētos konteinerus. Ja vēlamies dzēst ne tikai apturētos, bet arÄ« darbojoÅ”os konteinerus, mums vajadzētu izmantot kādu no Ŕīm komandām:

# Historical command
$ docker rm -f $(docker ps ā€“aq)

# More recent command
$ docker container rm -f $(docker container ls -aq)

Sānu piezīmes: ja, startējot konteineru, izmantojat parametru -rm, tad, kad tas apstājas, tiks atbrīvota visa tā aizņemtā vieta diskā.

Diska attēlu izmantoÅ”ana

Pirms dažiem gadiem vairāku simtu megabaitu attēla izmērs bija pilnīgi normāls: Ubuntu attēls svēra 600 megabaitus, bet Microsoft .Net attēls svēra vairākus gigabaitus. Šajos pinkainajos laikos tikai viena attēla lejupielāde var ievērojami samazināt brīvo vietu diskā, pat ja kopīgojat līmeņus starp attēliem. Šodien - lai slavēts - attēli sver daudz mazāk, taču, neskatoties uz to, jūs varat ātri aizpildīt pieejamos resursus, ja neveicat dažus piesardzības pasākumus.

Ir vairāki attēlu veidi, kas nav tieÅ”i redzami gala lietotājam:

  • starpattēli, uz kuru pamata tiek vākti citi attēli - tos nevar izdzēst, ja izmantojat konteinerus, kuru pamatā ir Å”ie ā€œcitiā€ attēli;
  • karājoÅ”ie attēli ir starpattēli, uz kuriem nav atsauces nevienā no esoÅ”ajiem konteineriem ā€” tos var izdzēst.
  • Izmantojot Å”o komandu, varat pārbaudÄ«t, vai sistēmā nav karājoÅ”o attēlu:

$ docker image ls -f dangling=true
REPOSITORY  TAG      IMAGE ID         CREATED             SIZE
none      none   21e658fe5351     12 minutes ago      71.3MB

JÅ«s varat tos noņemt Ŕādi:

$ docker image rm $(docker image ls -f dangling=true -q)

Varam izmantot arī plūmju apakŔkomandu:

$ docker image prune
WARNING! This will remove all dangling images.
Are you sure you want to continue? [y/N] y
Deleted Images:
deleted: sha256:143407a3cb7efa6e95761b8cd6cea25e3f41455be6d5e7cda
deleted: sha256:738010bda9dd34896bac9bbc77b2d60addd7738ad1a95e5cc
deleted: sha256:fa4f0194a1eb829523ecf3bad04b4a7bdce089c8361e2c347
deleted: sha256:c5041938bcb46f78bf2f2a7f0a0df0eea74c4555097cc9197
deleted: sha256:5945bb6e12888cf320828e0fd00728947104da82e3eb4452f

Total reclaimed space: 12.9kB

Ja mēs pēkŔņi vēlamies dzēst visus attēlus kopā (un ne tikai karājoties) ar vienu komandu, mēs varam darÄ«t Ŕādi:

$ docker image rm $(docker image ls -q)

Diska lietojums pēc apjomiem

Sējumi tiek izmantoti datu glabāŔanai ārpus konteinera failu sistēmas. Piemēram, ja mēs vēlamies saglabāt lietojumprogrammas rezultātus, lai tos izmantotu citā veidā. IzplatÄ«ts piemērs ir datu bāzes.

Palaidīsim MongoDB konteineru, pievienosim konteineram ārēju sējumu un atjaunosim no tā datu bāzes dublējumu (tas ir pieejams failā bck.json):

# Running a mongo container
$ docker run --name db -v $PWD:/tmp -p 27017:27017 -d mongo:4.0

# Importing an existing backup (from a huge bck.json file)
$ docker exec -ti db mongoimport 
  --db 'test' 
  --collection 'demo' 
  --file /tmp/bck.json 
  --jsonArray

Dati atradÄ«sies resursdatora direktorijā /var/lib/docker/volumes. Bet kāpēc ne konteinera lasÄ«Å”anas-rakstÄ«Å”anas lÄ«menÄ«? Tā kā MongoDB attēla Dockerfile direktorijs /data/db (kurā MongoDB pēc noklusējuma saglabā savus datus) ir definēts kā sējums.

Docker padomi: iztīriet savu ierīci no nevēlamā

Sānu piezÄ«me: daudzi attēli, kuriem jārada dati, izmanto apjomu, lai saglabātu Å”os datus.

Kad mēs pietiekami spēlējam ar MongoDB un apturēsim (vai varbÅ«t pat izdzēsÄ«sim) konteineru, sējums netiks izdzēsts. Tas turpinās aizņemt mÅ«su dārgo vietu diskā, lÄ«dz mēs to skaidri izdzēsÄ«sim ar Ŕādu komandu:

$ docker volume rm $(docker volume ls -q)

Nu, vai arÄ« mēs varam izmantot mums jau pazÄ«stamo plÅ«mju apakÅ”komandu:

$ docker volume prune
WARNING! This will remove all local volumes not used by at least one container.
Are you sure you want to continue? [y/N] y
Deleted Volumes:
d50b6402eb75d09ec17a5f57df4ed7b520c448429f70725fc5707334e5ded4d5
8f7a16e1cf117cdfddb6a38d1f4f02b18d21a485b49037e2670753fa34d115fc
599c3dd48d529b2e105eec38537cd16dac1ae6f899a123e2a62ffac6168b2f5f
...
732e610e435c24f6acae827cd340a60ce4132387cfc512452994bc0728dd66df
9a3f39cc8bd0f9ce54dea3421193f752bda4b8846841b6d36f8ee24358a85bae
045a9b534259ec6c0318cb162b7b4fca75b553d4e86fc93faafd0e7c77c79799
c6283fe9f8d2ca105d30ecaad31868410e809aba0909b3e60d68a26e92a094da

Total reclaimed space: 25.82GB
luc@saturn:~$

Diska izmantoÅ”ana attēlu veidoÅ”anas keÅ”atmiņai

Programmā Docker 18.09 attēla izveides procesā ir veiktas dažas izmaiņas, pateicoties rÄ«kam BuildKit. Å Ä« lieta palielina procesa ātrumu un optimizē datu glabāŔanu un droŔības pārvaldÄ«bu. Å eit mēs neapsvērsim visas Ŕī brÄ«niŔķīgā rÄ«ka detaļas; mēs koncentrēsimies tikai uz to, kā tas risina problēmas ar diska vietas izmantoÅ”anu.

Pieņemsim, ka mums ir pavisam vienkārÅ”a Node.Js lietojumprogramma:

  • fails index.js palaiž vienkārÅ”u HTTP serveri, kas atbild ar rindiņu uz katru saņemto pieprasÄ«jumu:
  • fails package.json definē atkarÄ«bas, no kurām HTTP servera palaiÅ”anai tiek izmantots tikai expressjs: 

$ cat index.js
var express = require('express');
var util    = require('util');
var app = express();
app.get('/', function(req, res) {
  res.setHeader('Content-Type', 'text/plain');
  res.end(util.format("%s - %s", new Date(), 'Got Request'));
});
app.listen(process.env.PORT || 80);

$ cat package.json
    {
      "name": "testnode",
      "version": "0.0.1",
      "main": "index.js",
      "scripts": {
        "start": "node index.js"
      },
      "dependencies": {
        "express": "^4.14.0"
      }
    }

Docker fails attēla izveidei izskatās Ŕādi:

FROM node:13-alpine
COPY package.json /app/package.json
RUN cd /app && npm install
COPY . /app/
WORKDIR /app
EXPOSE 80
CMD ["npm", "start"]

Veidosim attēlu parastajā veidā, neizmantojot BuildKit:

$ docker build -t app:1.0 .

Ja pārbaudām diska vietas lietojumu, mēs varam redzēt, ka vietu aizņem tikai pamata attēls (node:13-alpine) un mērķa attēls (app:1.0):

TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         2          0          109.3MB    109.3MB (100%)
Containers     0          0          0B         0B
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

Izveidosim otro mūsu lietojumprogrammas versiju, izmantojot BuildKit. Lai to izdarītu, mums vienkārŔi jāiestata mainīgais DOCKER_BUILDKIT uz 1:

$ DOCKER_BUILDKIT=1 docker build -t app:2.0 .

Ja mēs tagad pārbaudÄ«sim diska lietojumu, mēs redzēsim, ka tagad tajā ir iesaistÄ«ta veidoÅ”anas keÅ”atmiņa (buid-cache):

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         2          0          109.3MB    109.3MB (100%)
Containers     0          0          0B         0B
Local Volumes  0          0          0B         0B
Build Cache    11         0          8.949kB    8.949kB

Lai to notīrītu, izmantojiet Ŕo komandu:

$ docker builder prune
WARNING! This will remove all dangling build cache.
Are you sure you want to continue? [y/N] y
Deleted build cache objects:
rffq7b06h9t09xe584rn4f91e
ztexgsz949ci8mx8p5tzgdzhe
3z9jeoqbbmj3eftltawvkiayi

Total reclaimed space: 8.949kB

Iztīrīt visu!

Tātad, mēs apskatÄ«jām konteineru, attēlu un sējumu aizņemtās diska vietas attÄ«rÄ«Å”anu. To mums palÄ«dz žāvētu plÅ«mju apakÅ”komanda. Taču to var izmantot arÄ« doku sistēmas lÄ«menÄ«, un tas attÄ«rÄ«s visu iespējamo:

$ docker system prune
WARNING! This will remove:
  - all stopped containers
  - all networks not used by at least one container
  - all dangling images
  - all dangling build cache

Are you sure you want to continue? [y/N]

Ja kāda iemesla dēļ ietaupa vietu diskā datorā, kurā darbojas Docker, tad periodiskai Ŕīs komandas palaiÅ”anai vajadzētu kļūt par ieradumu.

Avots: www.habr.com

Pievieno komentāru