Definitivní průvodce zálohováním a obnovou kontejnerů Docker [Cloud + místní přístup pro samostatné servery]

Jak jste možná slyšeli frázi záloha není dobrá, pokud ji nelze obnovit .

Existuje celá řada způsobů, jak zálohovat základní soubory na cloudový server. Důležité je ale také to, abyste měli vždy aktualizovanou kopii těchto souborů ve svém místním umístění systémy.

Jejich zálohování v cloudu je v pořádku. Ale skutečná záloha je pouze čerstvá a pravidelně aktualizovaná kopie, která je na vaší straně neustále k dispozici. Proč? Protože jsou to VAŠE data!

Dvě výzvy, kterým se v tomto ohledu budu věnovat, jsou :

1. Nutnost zastavit kontejnery Docker na produkčním serveru, aby se předešlo možnému poškození dat (zejména databází) při zálohování. Soubory na živých produkčních kontejnerech se nepřetržitě zapisují.
2. Zastavení kontejnerů Docker má také za následek prostoje, a to si nemůžete dovolit, zvláště pokud jste ve výrobě.

Tyto problémy lze vyřešit použitím clusterů namísto jednotlivých serverů. Ale zde se zaměřuji na jednotlivé servery a ne na clustery aby byly výdaje na cloudové služby co nejnižší.

Stále jsem přemýšlel, jak se postarat o výše uvedené dvě výzvy. Pak mě napadlo, že můžeme využít kombinaci cloudu a lokalizovaného řešení.

Cloudovými řešeními mám na mysli zálohovací služby poskytované poskytovateli cloudových služeb, jako jsou Linode, Digital Ocean a další. V tomto návodu budu používat Linode.

Lokalizovanými řešeními mám na mysli použití příkazového řádku nebo nástrojů založených na grafickém uživatelském rozhraní ke stažení zálohy z cloudových serverů do vašeho místního systému / plochy. Zde jsem použil sftp (založený na příkazech).

Nejprve proberu, jak provést zálohu, a poté, jak ji také obnovit.

Postup zálohování v cloudu + místní

Nejprve se podívejme na postup zálohování.

Povolení zálohování na produkčním serveru Linode (v případě, že jste tak ještě neučinili)

Pokud na Linode používáte produkční server, důrazně se doporučuje, abyste pro něj povolili zálohování při každém jeho prvním nasazení. „Nanode“, jak se nazývá, je dodáván s 1 GB RAM a nabízí následující plán zálohování:

Všechna ostatní řešení zálohování nabízejí podobnou funkci, ale za vyšší sazby. Ujistěte se, že ji máte povolenou.

Pořídit ruční snímek jako zálohu v cloudu

Zadejte datum pro budoucí použití. Tady tomu říkám "manual-snapshot-11-05-21".

Jakmile na něj kliknete, budete požádáni o potvrzení:

Po potvrzení najdete vpravo dole upozornění:

Průběh můžete sledovat na stejné stránce, vedle toho, kde je uvedeno, že váš server běží (vlevo nahoře):

Jakmile to bude hotové, všimnete si zálohy jako čtvrté v seznamu.

Klonování produkčního serveru

I když můžete přímo klonovat server (na základě dříve naplánovaných záloh) z panelu Linode, doporučuji vám použít ruční zálohování, jak je popsáno v kroku výše.

Chcete-li tedy pokračovat ve vytváření klonu na základě poslední ruční zálohy, kterou jste provedli, ujistěte se, že dodržujete níže uvedené pokyny:

Přejděte na panel Linode a klikněte na „Vytvořit“:

Vyberte "Linode":

Vyberte kartu „Zálohy“:

Všimněte si, že snímek, který pořizujete, je založen na 2 GB Linode. Vyberte ruční snímek, který jste právě vytvořili:

Nyní se ujistěte, že jste pro svůj klon vybrali stejnou specifikaci (2 GB Linode Plan):

Poté, co vytvoříte nový server na základě zálohy produkčního serveru, budete mít k dispozici snadno dostupný klon produkčního serveru.

Přihlaste se ke klonu přes ssh a zastavte všechny kontejnery

S přihlášením k novému klonu přes ssh byste neměli mít žádné problémy, protože používá stejné veřejné klíče jako produkční server. Stačí použít novou IP klonu. Předpokládám, že používáte ssh samostatně a máte vypnuté ověřování na základě hesla, že? Pokud jste tak dosud neučinili, přečtěte si tuto příručku zabezpečení ssh.

Po přihlášení zastavte všechny kontejnery, jejichž data chcete zálohovat. Obvykle byste se přesunuli do příslušných adresářů aplikací a použili příkaz docker-compose down. V typickém produkčním prostředí se vždy očekává, že budete používat Docker Compose namísto konvenčního docker stop příkaz, který by měl být preferován pouze během testování.

Například, kdybych měl spuštěný Ghost s odpovídajícím databázovým kontejnerem, nejprve bych zkontroloval jeho příslušné informace:

[email protected]:~$ docker ps
CONTAINER ID   IMAGE                                    COMMAND                  CREATED        STATUS       PORTS                                      NAMES
6a3aafe12434   ghost:4.4.0                              "docker-entrypoint.s…"   7 days ago     Up 7 days    2368/tcp                                   ghost_ghost_2
95c560c0dbc7   jrcs/letsencrypt-nginx-proxy-companion   "/bin/bash /app/entr…"   6 weeks ago    Up 10 days                                              letsencrypt-proxy-companion
6679bd4596ba   jwilder/nginx-proxy                      "/app/docker-entrypo…"   6 weeks ago    Up 10 days   0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp   jwilder-nginx-proxy
1770dbb5ba32   mariadb:10.5.3                           "docker-entrypoint.s…"   3 months ago   Up 10 days                                              ghost_db_1

Jak můžete vidět zde, názvy kontejnerů jsou ghost_ghost_2 a ghost_db_1 respektive běží pod reverzním proxy. Zastavme je.

[email protected]:~$ cd ghost
[email protected]:~/ghost$ docker-compose down
Stopping ghost_ghost_2 ... done
Stopping ghost_db_1    ... done
Network net is external, skipping
[email protected]:~/ghost$ 

V případě, že za konfigurací reverzního proxy serveru nginx běží více aplikací, použijte stejný postup s příslušnými názvy adresářů nastavenými pro aplikace. Zastavte je všechny jednoho po druhém.

Zálohovat svazky a nastavení jako archivy gzip

Nyní se podívejme na proces ručního zálohování.

Zálohování pojmenovaných svazků

Když máte co do činění s pojmenovanými svazky Docker, poznamenejte si, zda byly svazky vytvořeny ručně, nebo zda byly založeny na obecné konfiguraci Docker Compose, kterou byla aplikace poprvé nasazena.

Obecná konfigurace v sekci svazků vypadá takto:

volumes:
  ghost:
  ghostdb:

Výše uvedený scénář spravuje Docker Compose a skutečné názvy svazků, které byste potřebovali pro zálohování, budou ghost_ghost a ghost_ghostdb .

V případě, že byly svazky vytvořeny ručně pomocí docker volume create volume-name , bude konfigurace vypadat následovně a bude striktně ghost a ghostdb sám:

volumes:
  ghost:
    external: true
  ghostdb:
    external: true

V obou případech je však musíte zálohovat a také musíte zkontrolovat cesty na kontejnerech, když jsou svazky připojeny. Například v typické konfiguraci Ghost s MariaDB mohou být cesty známé pohledem na podsekce svazků uvnitř definic služeb. Zde je úryvek, který vám ukáže, co tím myslím:

    ghostdb:
        volumes:
            - ghostdb:/var/lib/mysql

Výše uvedená konfigurace je součástí databázové služby a jejího odpovídajícího kontejneru, který by byl vytvořen po nasazení.

Podobně pro samotnou službu duchů je cesta /var/lib/ghost/content :

    ghost:
        volumes:
            - ghost:/var/lib/ghost/content

Tyto cesty potřebujete znát, abyste mohli zálohovat své svazky.

Použijte docker volume ls pro dvojitou kontrolu názvů svazků přítomných na klonovaném serveru.

[email protected]:~/ghost$ docker volume ls
DRIVER    VOLUME NAME
local     ghost
local     ghostdb
local     nginx-with-ssl_acme
local     nginx-with-ssl_certs
local     nginx-with-ssl_dhparam
local     nginx-with-ssl_html
local     nginx-with-ssl_vhost

Můžete tedy potvrdit, že svazky jsou skutečně ghost a ghostdb .

Je čas je zálohovat! Na produkčním klonu nyní vytvoříme záložní adresář ve vašem uživatelském adresáři:

mkdir ~/backup

Nyní použiji následující příkaz k zálohování obsahu svazků v archivu tar:

docker run --rm -v ghostdb:/var/lib/mysql -v ~/backup:/backup ubuntu bash -c "cd /var/lib/mysql && tar cvzf /backup/ghostdb.tar.gz ."

Ve výše uvedeném příkazu pomocí -v nebo --volume , připojím existující svazek dockeru k novému kontejneru Ubuntu a také připojím záložní adresář, který jsem právě vytvořil. Později se přesunu do adresáře databáze uvnitř kontejneru a pomocí tar archivuji jeho obsah. --rm se používá k automatickému vyčištění kontejneru a odstranění jeho souborového systému při ukončení kontejneru (protože to chcete pouze do doby, než bude dokončena úloha zálohování nebo obnovení).

Všimněte si tečky na konci výše uvedeného příkazu před koncem quote("). Zajistí, aby archiv obsahoval to, co je uvnitř /var/lib/ghost/content samostatně a nezahrnuje celou cestu samotnou jako podadresáře. Ten způsobí problémy při obnově archivu na nový svazek na novém serveru. Mějte to prosím na paměti.

Nyní mám archiv svazku databáze MariaDB, který používá náš blog Ghost. Podobně musím také zálohovat svazek duchů:

docker run --rm -v ghost:/var/lib/ghost/content -v ~/backup:/backup ubuntu bash -c "cd /var/lib/ghost/content && tar cvzf /backup/ghost.tar.gz ."

Pamatujte, že výše uvedené příkazy k zálohování jsou založeny na externích svazcích, které byly původně vytvořeny ručně. U obecných svazků vytvořených a spravovaných pomocí Docker Compose by skutečné názvy svazků byly ghost_ghost a ghost_ghostdb resp. Například pro ghost_ghostdb , ghost prefix odkazuje na název adresáře vaší aplikace, kde máte konfigurační soubory Docker Compose a ghostdb odkazuje na název svazku, který jste nastavili v konfiguraci Docker Compose.

Nastavení zálohování s připojením nebo bez připojení

Také si uvědomte, že musíte archivovat adresář ghost docker compose bez ohledu na to, zda používáte připojená připojení nebo pojmenované svazky, protože zde jsou uloženy vaše konfigurační soubory.

V případě, že používáte připojení připojení a nepojmenujete svazky Docker, bude celý adresář archivován včetně připojení připojení. Zde to nazývám ghost-docker-compose.tar.gz aby nedošlo k záměně:

[email protected]:~/ghost$ sudo tar cvzf ~/backup/ghost-docker-compose.tar.gz .

Svázat připojené svazky nepotřebují samostatnou sekci svazků v souboru Docker Compose. Při definování uvnitř služby by chtěli pouze následující:

    ghost:
        volumes:
            - ./ghost:/var/lib/ghost/content

Podobně by svazek připojené databáze vypadal takto:

    ghostdb:
        volumes:
            - ./ghostdb:/var/lib/mysql

"./" označuje adresář připojený k vazbě uvnitř stejného adresáře duchů, do kterého jsme se právě "cd" dostali. Proto v tomto případě provedete kompletní zálohu všech souborů (včetně svazků a konfiguračních souborů).

Záložní svázaná připojení jako pojmenované svazky

Alternativně můžete také jednotlivě zálohovat připojení. To vám dává možnost vybrat si, zda chcete, aby měl váš nový server připojenou vazbu nebo konfiguraci pojmenovaného svazku na Dockeru. Důvodem je, že archivy jsou zálohovány stejným způsobem jako pojmenované svazky popsané výše. Chcete-li to provést, musíte jeden po druhém "cd" do adresáře aplikace a databáze (připojení vazby).

cd ~/ghost/ghost
sudo tar cvzf ~/backup/ghost.tar.gz .
cd ~/ghost/ghostdb
sudo tar cvzf ~/backup/ghostdb.tar.gz .

Jak připojení připojení, tak pojmenované svazky mají své výhody a nevýhody. Otázka, který z nich je nejideálnější, se liší od aplikace k aplikaci. Vývojáři Nextcloud například navrhují pojmenované svazky, zatímco vývojáři Rocket.Chat navrhují připojení připojení.

Pokračujeme, je načase, abyste ty archivy stáhli na svém konci.

Stáhněte si archivy do místního systému pomocí sftp

Pomocí sftp můžete své archivy okamžitě stáhnout do místního systému. Zde jako příklad používám port 4480 a IP 12.3.1.4. Odkazuje na stejný port, jaký používá ssh.

[email protected]:~$ sftp -oPort=4480 [email protected]
Connected to 12.3.1.4.
sftp> get /home/avimanyu/backup/ghost.tar.gz /home/user/Downloads
Fetching /home/avimanyu/backup/ghost.tar.gz to /home/user/Downloads/ghost.tar.gz
/home/avimanyu/backup/ghost.tar.gz                                                                                                                                                                                                                                                         100%  233MB   6.9MB/s   00:34    
sftp> get /home/avimanyu/backup/ghostdb.tar.gz /home/user/Downloads
Fetching /home/avimanyu/backup/ghostdb.tar.gz to /home/user/Downloads/ghostdb.tar.gz
/home/avimanyu/backup/ghostdb.tar.gz                                                                                                                                                                                                                                                       100%   26MB   6.5MB/s   00:03  
sftp> get /home/avimanyu/backup/ghost-docker-compose.tar.gz /home/user/Downloads
Fetching /home/avimanyu/backup/ghost-docker-compose.tar.gz to /home/user/Downloads/ghost-docker-compose.tar.gz
/home/avimanyu/backup/ghost-docker-compose.tar.gz                                                                                                                                                                                                                                          100%  880     6.0KB/s   00:00
sftp> exit
[email protected]:~$

Jak můžete vidět zde, get příkaz na sftp je mnohem rychlejší než rsync nebo scp . Jednou je stahování dokončeno, zobrazí se výzva sftp, kde můžete zadat exit a vyjděte z konzoly sftp. Stažené soubory budou dostupné na /home/user/Downloads .

V tomto okamžiku můžete říci, že jste provedli kompletní zálohu aplikace dockeru.

Ale jak musím znovu říci, není to dobré, pokud to nemůžete obnovit.

Postup obnovy

Nyní, když víte, jak provést zálohu, je čas podívat se, jak obnovit ze zálohy.

Vytvořit nový server v cloudu

Vytvořte nový server z řídicího panelu cloudové služby. Probíral jsem to v naší záložní sekci. Na Linode to vypadá takto:

Doporučuje se zachovat specifikace serveru stejné jako u původního serveru, ze kterého byly archivy zálohovány (zmíněno dříve).

Nahrát archivy záloh na nový server

Za předpokladu, že se nyní můžete přihlásit k novému serveru na základě uložených nastavení ssh u poskytovatele cloudových služeb, nahrajte soubory na server pomocí put sftp příkaz:

[email protected]:~$ sftp -oPort=4480 [email protected]
Connected to 12.3.1.5.
sftp> put /home/user/Downloads/ghostdb.tar.gz /home/avimanyu
Uploading /home/user/Downloads/ghostdb.tar.gz to /home/avimanyu/ghostdb.tar.gz
/home/iborg/Downloads/ghostdb.tar.gz                                                                                                                                                                                                                                                       100%   26MB   6.2MB/s   00:04    
sftp> put /home/user/Downloads/ghost.tar.gz /home/avimanyu
Uploading /home/user/Downloads/ghost.tar.gz to /home/avimanyu/ghost.tar.gz
/home/iborg/Downloads/ghost.tar.gz                                                                                                                                                                                                                                                         100%  233MB   7.2MB/s   00:32  
sftp> put /home/user/Downloads/ghost-docker-compose.tar.gz /home/avimanyu
Uploading /home/user/Downloads/ghost-docker-compose.tar.gz to /home/avimanyu/ghost-docker-compose.tar.gz
/home/iborg/Downloads/ghost-docker-compose.tar.gz                                                                                                                                                                                                                                          100%  880    22.6KB/s   00:00 
sftp> exit
[email protected]:~$ 

Pokud dáváte přednost použití GUI pro nahrávání, můžete stále používat FileZilla.

Obnovení nastavení a svazků

Nejprve obnovte docker compose adresář vaší konfigurace Ghost.

mkdir ghost
cd ghost
sudo tar xvf ~/backup/ghost-docker-compose.tar.gz

Alternativně můžete také zkusit obnovit vlastnictví uživatele (oprávnění jsou již zachována), což může být užitečné při obnově připojených adresářů (již přítomných v archivech), pomocí --same-owner :

sudo tar --same-owner -xvf ~/backup/ghost-docker-compose.tar.gz

V případě, že se chcete při správě nových svazků spolehnout na Docker Compose, nejprve je vytvořte. Podle naší diskuse v sekci zálohovaných svazků výše byste zjevně museli dodržovat nezbytné konvence pojmenování:

docker volume create ghost_ghost
docker volume create ghost_ghostdb

Pokud je chcete v konfiguraci Docker Compose nastavit jako externí, názvy by se musely lišit (upravte dva výše uvedené příkazy):

docker volume create ghost
docker volume create ghostdb

Chcete-li obnovit svazek MariaDB pro Ghost:

docker run --rm -v ghostdb:/restore -v ~/backup:/backup ubuntu bash -c "cd /restore && tar xvf /backup/ghostdb.tar.gz"

Obnovení samotného svazku Ghost:

docker run --rm -v ghost:/restore -v ~/backup:/backup ubuntu bash -c "cd /restore && tar xvf /backup/ghost.tar.gz"

Ujistěte se, že nastavení DNS jsou obnovena na základě nové IP adresy

Vzhledem k tomu, že používáte nový server, IP se určitě změnila, a proto musí být revidována pro vaši doménu. Tyto předpoklady reverzního proxy dockeru nginx můžete zkontrolovat jako referenci tam, kde to bylo probráno.

Spuštění nových kontejnerů s nezbytnými nastaveními a obnovenými svazky

Nyní znovu spusťte konfiguraci na novém serveru:

docker-compose up -d

Pokud budete důsledně dodržovat všechny výše uvedené pokyny, budete mít nyní plně obnovenou webovou aplikaci Docker na základě vaší zálohy.

Zničte klon

Jakmile dosáhnete svého cíle, není již potřeba mít klon, pokud si jej nechcete ponechat pro testování. Takže pokud už to nechcete, smažte prosím Linode (DVOJNÁSOBNÁ KONTROLA!):

Závěrečné myšlenky

Existuje již mnoho řešení, která využívají takové metody po částech a částech. To však vyžaduje prostoje, protože kontejnery musí být zastaveny. Tato výzva je řešena pomocí cloudových záloh z produkčních klonů, nikoli samotných produkčních serverů.

Namísto použití 24/7 dalšího serveru jako clusteru pro zálohování bez výpadků používáme pouze jeden, abychom zajistili totéž. To umožňuje lepší FinOps.

Pokud dáváte přednost použití GUI pro stahování nebo nahrávání záloh, můžete použít sftp přes FileZilla.

Vzhledem k tomu, že zálohujete soubory na klonovaném serveru a nikoli na samotném produkčním serveru, ušetříte drahocennou dobu provozuschopnosti a navíc se vyhnete neočekávaným škytavkám, se kterými se můžete během procesu setkat. Abych byl upřímný, můžete se zbavit jakýchkoli starostí a hrát si s tím bez napětí, protože se nedotýkáte produkčního serveru;)

Nelze popřít, že celý proces je poměrně obsáhlý, ale určitě se postará o náš cíl. Když se podíváme dál, tento postup by mohl být v budoucnu zcela automatizován s pečlivou synchronizací mezi cloudem a vaším místním systémem.

Pokud máte další návrhy na zálohování a obnovení Dockeru bez prostojů, podělte se o své myšlenky v části níže. Jakékoli další zpětné vazby nebo komentáře jsou velmi vítány.