DevOps-2: Dokeruj swoją aplikację Golang z bazą danych PostgreSQL.

May 05 2023
Jeśli chcesz przeczytać pierwszą część, kliknij tutaj Soo! Hej dobrzy ludzie! Dziękujemy za kontynuację czytania drugiej części serii dotyczącej dokowania aplikacji Golang z bazą danych Postgresql. W ostatnim artykule napisaliśmy prostą aplikację golang CRUD i uruchomiliśmy aplikację poprzez dokeryzację bazy danych postgreSQL.

Jeśli chcesz przeczytać pierwszą część, kliknij tutaj

Tak! Hej dobrzy ludzie! Dziękujemy za kontynuację czytania drugiej części serii dotyczącej dokowania aplikacji Golang z bazą danych Postgresql.

W ostatnim artykule napisaliśmy prostą aplikację golang CRUD i uruchomiliśmy aplikację poprzez dokeryzację bazy danych postgreSQL. Zaczynamy drugą część.

Na początek przeanalizujemy i wyjaśnimy plik docker-compose dla bazy danych postgresql. Plik docker-compose został zapisany jako:

version: '3'

services:
  db:
    image: postgres:13-alpine
    restart: always
    environment:
      POSTGRES_USER: admin
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: go-app
    ports:
      - "5432:5432"

Potem przychodzi następna część, w której zadeklarowaliśmy usługi. Czym jest tutaj służba?

Słuchaj, podczas tworzenia oprogramowania używamy wielu narzędzi, takich jak baza danych, redis, rabbitmq i tak dalej. Wszystkie te narzędzia, których używamy podczas tworzenia oprogramowania, używamy ich instalując na naszej maszynie. Docker pomaga nam korzystać z tych narzędzi bez instalacji iw bardzo łatwy sposób. Te narzędzia są w rzeczywistości usługą pliku tworzenia dokera. Tak więc w tej części pliku dotyczącej usług zapiszemy listę usług/narzędzi systemu. Tutaj korzystaliśmy tylko z usługi bazy danych, ale możemy korzystać z dowolnej ilości usług. Mam nadzieję, że ta linia jest jasna.

Przechodząc do następnej części, czyli obrazu. Jest to bardzo ważna część zrozumienia dokera i nie mówiliśmy o tym w poprzednim artykule. Co to jest obraz?

We wcześniejszym akapicie właśnie mówiliśmy o usługach pliku tworzenia dokera. Gdyby docker nie istniał, być może musielibyśmy zainstalować wszystkie narzędzia, których używamy do budowania i uruchamiania aplikacji. Prawidłowy?

Ale docker rozwiązuje ten problem w bardzo prostszy sposób. Pomyślmy o bazie danych postgresql. Gdybyśmy musieli ręcznie zainstalować bazę danych postgresql na naszym komputerze, domyślną nazwą użytkownika byłby postgres , ale tutaj używamy nazwy użytkownika jako admin. Jeśli chcielibyśmy użyć nazwy użytkownika administratora , musielibyśmy utworzyć użytkownika ręcznie, a następnie użyć tej nazwy. Ale prosty plik tworzenia dokera rozwiązał ten problem. Nie zrobiliśmy nic poza zapisaniem nazwy użytkownika w pliku i wszystko zostało skonfigurowane automatycznie, prawda? . Ale jak to się stało?

Otwórz nową kartę w przeglądarce i odwiedź ten adres URL =>https://hub.docker.com/

Utwórz również konto, jeśli jeszcze go nie utworzyłeś. Wyszukaj postgresql, a zobaczysz wiele wyników postgresql. Wszystkie te wyniki są w rzeczywistości obrazami silnika dokera. Czym w takim razie jest obraz?

Obraz platformy Docker to spakowana i samodzielna aplikacja zawierająca wszystkie niezbędne pliki, zależności i konfiguracje wymagane do uruchomienia aplikacji w środowisku kontenerowym. Która aplikacja? Aplikacje takie jak baza danych, system operacyjny, redis itp.

Mam nadzieję, że masz teraz podstawowe pojęcie o obrazie, ale o kontenerze mówiliśmy w poprzednim artykule. Czym w takim razie jest kontener? Widzisz, właśnie powiedzieliśmy, obraz jest plikiem konfiguracyjnym dowolnego narzędzia. Jeśli chcemy użyć tego narzędzia, tak naprawdę najpierw pobieramy obraz z dockerhub, a następnie uruchamiamy obraz na silniku dokera. Ta działająca instancja obrazu jest kontenerem. Łatwe, prawda?

W pliku docker compose zapisaliśmy nazwę obrazu postgres, który jest już w dockerhub. Dla każdego obrazu otrzymasz wszystkie wersje dostępne dla tego obrazu na dockerhub. Oddzielona kolorem następna część to tak naprawdę wersja obrazu. To jest jak,

image: postgres:13-alpine
# image name is: postgres 
# version is: 13-alpine.

Następnie zadeklarowaliśmy zmienną środowiskową, taką jak nazwa użytkownika, hasło i nazwa bazy danych.

Następna część definiuje mapowanie portów. Przypomnijmy, że w poprzednim artykule, gdy nie mapowaliśmy portu, aplikacja nie mogła połączyć się z bazą danych, ale po zmapowaniu portu działała. Dlaczego tak? Ponieważ,

ports:
  -"5432:5432"

Naprawdę mam nadzieję, że zrozumiałeś całą konfigurację pliku tworzenia pliku dokera.

Ale może pojawić się pytanie, jak ludziom udało się zbudować obrazy dla dockerhuba z konfiguracją. Co to za konfiguracje? Czy my też możemy to zrobić?

Tak, oczywiście!

Pamiętasz aplikację, którą napisaliśmy w golangu i uruchamialiśmy ją za pomocą polecenia „ go run main.go ”?

Teraz zbudujemy obraz z tej aplikacji go, abyśmy mogli uruchomić aplikację w taki sam sposób, w jaki uruchamiamy bazę danych postgresql za pomocą polecenia docker run. Zacznijmy…

Czekać! Nauczmy się czegoś jeszcze, zanim przejdziemy do tworzenia obrazu na serwer.

Wiesz, go jest skompilowanym językiem i możemy zbudować wykonywalny plik binarny z kodu go. Co to robi? Po skompilowaniu całego kodu źródłowego generowany jest plik binarny i możemy uruchomić aplikację tylko z pliku binarnego bez posiadania kodu źródłowego. Fajne, prawda?

Jak więc możemy zbudować plik binarny? Otwórz terminal i wpisz

$ go build -o main .

Uruchom kontener bazy danych, jeśli go zatrzymałeś, ponieważ aplikacja spróbuje połączyć się z bazą danych i otworzyć inny terminal i wpisać:

$ ./main

Krok 4: Tworzenie obrazu dla serwera go.

Utwórz nowy plik o nazwie „Dockerfile”, otwórz plik i zapisz w nim tę konfigurację.

FROM golang:1.19-alpine3.16 AS build
WORKDIR /app
COPY . .
RUN go build -o main .


FROM alpine:3.14
WORKDIR /app
COPY --from=build /app/main .
CMD ["/app/main"]

$ docker build -t go .

$ docker images

$ docker run go

Znajdźmy nasze, co jest nie tak. Spójrz na dziennik błędów. Powinno być tak:

$ docker run go
2023/05/04 18:19:16 dial tcp 127.0.0.1:5432: connect: connection refused

Oh! zapomniałeś o uruchomieniu bazy danych? Zrób to teraz i spróbuj ponownie wykonać powyższe polecenia.

Więc nasza baza danych działa, nasz kontener aplikacji działa, ale nie mogą się połączyć, dlaczego?

Pamiętaj o wierszu, który powiedziałem w poprzednim artykule: „Kontener Dockera jest odizolowany od siebie (jeden kontener do drugiego) i hosta. Ponieważ tworzy wirtualną sieć”

Powiedziałem również, że sieć wirtualna jest jak różne komputery, które nie są podłączone do Internetu i dlatego nie mogą się ze sobą łączyć.

Tutaj nasza baza danych działa w jednej sieci wirtualnej, a serwer działa w innej. Jak w takim razie możemy je ze sobą połączyć?

Teraz przejdziemy do zrozumienia koncepcji sieci dokerów.

Ale na dziś wystarczy czytania teorii. Nauczmy się sieci dokerów w następnym artykule.

Gdy trzeci artykuł będzie gotowy, zamieszczę go tutaj.

Dziękujemy za poświęcony czas i zainteresowanie.