Czym jest Docker i dlaczego programiści powinni się go uczyć?
Praktyczne wyjaśnienie Docker dla programistów: kontenery vs maszyny wirtualne, polecenia podstawowe, Dockerfiles i jak zacząć go używać w rzeczywistych projektach.
Docker pojawia się w ofertach pracy i przewodnikach konfiguracji, a jeśli nigdy nie miałeś kontaktu z kontenerami, może wydawać się to przeszkodą którą musisz pokonać zanim napiszesz rzeczywisty kod. To nie jest skomplikowane, gdy przejdziesz przez słownictwo.
Czym naprawdę jest kontener
Kontener pakuje twoją aplikację razem ze wszystkim, czego potrzebuje do uruchomienia: kodem, środowiskiem uruchomieniowym, bibliotekami systemowymi i plikami konfiguracyjnymi. To nie jest maszyna wirtualna. Maszyna wirtualna wirtualizuje całe jądro systemu operacyjnego, co oznacza, że uruchomienie jej może trwać minutę i zjeść kilka gigabajtów RAM. Kontener dzieli się jądrem maszyny hosta i izoluje tylko proces, więc uruchamia się w poniżej sekundy i zazwyczaj zużywa dziesiątki megabajtów zamiast gigabajtów.
Ta różnica jest powodem, dla którego Docker tak szybko przejął lokalny development i pipeline'y CI. Możesz uruchomić bazę Postgres, cache Redis i serwer aplikacji na jednym laptopie bez instalowania ich bezpośrednio na swoim systemie operacyjnym.
Główne elementy, które musisz znać
Cztery pojęcia obejmują większość tego, z czym będziesz się spotykać każdego dnia:
- Image: szablon tylko do odczytu zbudowany z Dockerfile. Pomyśl o tym jako o migawce systemu plików plus metadane o tym, jak go uruchomić.
- Container: działająca instancja obrazu. Możesz uruchamiać, zatrzymywać i usuwać kontenery bez dotykania obrazu, z którego pochodzą.
- Dockerfile: plik tekstowy z instrukcjami do budowania obrazu, linia po linii.
- Registry: miejsce, gdzie obrazy są przechowywane i pobierane, najczęściej Docker Hub.
Minimalny Dockerfile dla aplikacji Node.js wygląda tak:
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]
Zbuduj go za pomocą docker build -t my-app . i uruchom za pomocą docker run -p 3000:3000 my-app. Flaga -p mapuje port na twojej maszynie na port wewnątrz kontenera, w ten sposób faktycznie docierasz do aplikacji z przeglądarki.
Polecenia, które będziesz używać ciągle
Garstek poleceń obejmuje większość codziennej pracy:
docker ps— wyświetl uruchomione kontenerydocker ps -a— wyświetl wszystkie kontenery, łącznie z zatrzymanymidocker images— wyświetl obrazy na twojej maszyniedocker logs <container>— sprawdź dane wyjściowe z uruchomionego lub zepsutegokonteneradocker exec -it <container> sh— otwórz powłokę wewnątrz uruchomionego konteneradocker rm/docker rmi— wyczyść kontenery i obrazy, które już nie potrzebujesz
Ta ostatnia para ma większe znaczenie niż się spodziewają ludzie. Docker chętnie pozwoli miejscu na dysku zniknąć w starych obrazach i zatrzymanych kontenerach. Uruchomienie docker system prune czasami odzyskuje zaskakującą ilość miejsca.
Dlaczego docker-compose zmienia przepływ pracy
Większa część rzeczywistych projektów potrzebuje więcej niż jednego kontenera: serwer aplikacji, bazę danych, może cache. Wpisywanie poleceń docker run dla każdego z nich szybko się nudzi. docker-compose.yml pozwala ci zdefiniować cały stos w jednym pliku:
services:
web:
build: .
ports:
- "3000:3000"
depends_on:
- db
db:
image: postgres:16
environment:
POSTGRES_PASSWORD: devpassword
volumes:
- db_data:/var/lib/postgresql/data
volumes:
db_data:
Uruchom docker compose up i oba serwisy startują razem, sieciowane tak że web może osiągnąć db po nazwie serwisu. To jest setup, który zobaczysz w prawie każdym README repozytorium open-source, i zrozumienie go oznacza, że możesz sklonować projekt i mieć go działającego w minuty zamiast ręcznego instalowania Postgres, Redis i czego innego aplikacja potrzebuje.
Gdzie ludzie się potykają wcześnie
Volumes dezorientują prawie każdego na początku. Bez volumesu, cokolwiek napisane wewnątrz kontenera znika gdy kontener zostaje usunięty, co jest problemem dla baz danych. Sekcja volumes w pliku compose powyżej mapuje nazwany volume do ścieżki wewnątrz kontenera tak że dane przeżywają restarty.
Inny częsty błąd to kopiowanie node_modules lub .git do obrazu ponieważ nie ma pliku .dockerignore. Dodaj jeden dokładnie jak .gitignore:
node_modules
.git
.env
To utrzymuje buildy szybsze i obrazy mniejsze, co ma znaczenie gdy zaczynasz pushować obrazy do registry'ego lub deployować na Kubernetes.
Gdzie iść po podstawach
Kiedy budowanie i uruchamianie kontenerów czuje się normalne, kolejne przydatne umiejętności to wieloetapowe buildy dla mniejszych obrazów produkcyjnych, zrozumienie trybów networkingu Docker i czytanie wyniku docker inspect gdy coś się nie łączy. Nic z tego nie jest trudne, jest to po prostu nieznajome za pierwszym razem.
Więcej o konteneryzacji rzeczywistych aplikacji i ich łączeniu z pipeline'ami deploymentu w chmurze znajduje się w segmentach DevOps i Cloud na Korra Studio.
Napisane z pomocą AI, zweryfikowane i opublikowane przez Michal Pilch (CISSP), Korra Studio.
To jedna notatka z bazy wiedzy Korra Studio — platforma łączy każdy temat z mentoringiem 1 na 1.
Zacznij za darmoarrow_forward