Darmowa chmura ~200GB na Twoje pliki

-> Go to english version of this post / Przejdź do angielskiej wersji tego wpisu

Mój wpis o darmowym serwerze VPS od Oracle jest prawdziwym hitem tego bloga. Patrząc na statystyki ma więcej odsłon niż wszystkie inne wpisy razem wzięte. Nic w tym dziwnego, gdyż chyba każdy lubi czasem trochę przycebulić i dostać coś fajnego za darmo. Oczywiście będą tutaj głosy mówiące, iż jak coś jest za darmo to towarem jesteśmy tak naprawdę my, a może raczej nasze dane. Pewnie tak, ale przyznam szczerze, iż ja osobiście nie zastanawiałem się dwa razy decydując się na skorzystanie z tej ciekawej promocji Oracle, w której można otrzymać tak naprawdę trzy serwery – jeden z 4-rdzeniowym procesorem o 24GB RAMu oparty o architekturę ARM, oraz dwa o znacznie słabszej mocy procesora (1/8 OCPU) i tylko 1GB RAM oparte na architekturze AMD. Ten pierwszy to prawdziwa kobyła, na której można zrobić naprawdę wiele kozackich rzeczy, a dwa pozostałe to takie satelity, które świetnie sprawdzają się jako poligony treningowe lub dla mniejszych projektów. Co interesujące w zeszłym tygodniu orałem moją całą infrastrukturę Oracle i stawiałem od zupełnego zera, co dało mi możliwość sprawdzenia czy opisany przeze mnie sposób dalej działa i muszę z przyjemnością powiedzieć, iż tak. Zatem oficjalnie odpowiadam na wiele zadanych mi w ostatnich miesiącach pytań – tak, serwery w ramach Always Free Tier są dalej normalnie dostępne, a mój poradnik aktualny.

Co interesującego zrobimy dzisiaj?

W dzisiejszym wpisie na tym darmowym VPS od Oracle postawimy prywatną chmurę na pliki, na której będziemy mogli przechowywać do blisko 200 GB danych. Zrobimy to poprzez uruchomienie kontenera Docker, w którego środku będzie Nextcloud, a zrobimy to przy użyciu Portainer. Do tego podepniemy do niego własną domenę, do czego wykorzystamy NGINX Proxy Manager, który będzie uruchomiony jako oddzielny kontener, oraz Cloudflare (choć dla chętnych, a raczej niechętnych do CF, opiszę również jak to zrobić przez FreeDNS::24). Oczywiście zadbamy także o szyfrowanie komunikacji, czyli SSL/HTTPS, co zrealizujemy również przez NGINX Proxy Manager używając certyfikatu Let’s Encrypt.

Spis treści

1. Pozyskanie darmowego serwera VPS od Oracle
2. Wstępna konfiguracja serwera
3. Zapora sieciowa
4. Docker i Portainer
5. Podpięcie domeny przez Cloudflare
6. Alternatywne rozwiązanie z FreeDNS::42 zamiast Cloudflare
7. NGINX Proxy Manager
8. Nextcloud i MariaDB
9. Zamykanie portów (aktualizacja 07-10-2024)

Pozyskanie darmowego serwera VPS od Oracle

Jeżeli nie masz jeszcze takiego serwera to cały proces opisałem naprawdę bardzo szczegółowo w oddzielnym wpisie. Na potrzeby tego poradnika proponuję utworzyć sobie instancję o następujących parametrach:

• domena – EU-Frankfurt-1 (ja ostatnio nie miałem problemów z uzyskaniem VPS dokładnie z domeny AD2),
• Shape (typ maszyny) – zakładka Virtual Machine i dalej Ampere, gdzie wybieramy konkretnie VM.Standard.A1.Flex,
• Image (obraz systemu) – Ubuntu 22.04, które zaktualizujemy do 24.04 LTS podczas początkowej konfiguracji, bo z niewiadomych mi przyczyn Oracle podaje, iż 24.04 LTS nie działa z tym typem maszyny na ARM (co jest nieprawdą i udowodnię to) i po prostu nie pozwala od razu zacząć od tego systemu,
• CPU – 4 rdzenie,
• RAM – 24GB, na potrzeby Nextcloud nie potrzebujemy aż tyle, ale nie ograniczajmy się i bierzmy maksymalną ilość, którą dają, bo w przyszłości pozwoli nam to na uruchomienie również innych rzeczy,
• publiczny adres IPv4 – pamiętaj, aby przypisać go do maszyny już podczas jej tworzenia co uprości cały proces, rozważ także przypisanie adresu IPv6, bo może Ci się przydać w przyszłości,
• klucze SSH – Oracle nie da Ci bez tego ruszyć dalej, co jest dobrą praktyką, więc po prostu zrób nowy klucz i go zapisz lub skorzystać ze swojego i podaj go Oracle,
• pojemność dysku – (określa się to w sekcji Boot volume po zaznaczeniu Specify a custom boot volume size) – za darmo możemy dostać maksymalnie 200GB do podziału na wszystkie maszyny, możesz przypisać wszystko do tej maszyny ARM albo podzielić to jakoś, tak aby również dla tych dwóch AMD coś zostało,
• szyfrowanie komunikacji pomiędzy instancją i magazynem – zaznacz opcję Use in-transit encryption.

Wstępna konfiguracja serwera

Zaczynamy standardowo o połączenia się z wcześniej utworzoną instancją. Ja przeważnie używam do tego celu aplikacji Termius, ale możesz też użyć PuTTY lub dowolnego innego sposobu pozwalającego na nawiązanie komunikacji SSH. To jak łączyć się z serwerami poprzez SSH opisałem w tym wpisie. Natomiast w tym wpisie to jak używać kluczy SSH. Nie będę tego wszystkie powtarzał jeszcze raz. Skupimy się tutaj jedynie na tym co dla konkretnego przypadku jest nieoczywiste. Do połączenia przez SSH potrzebujemy w zasadzie czterech rzeczy:

1. Adresu IP serwera
2. Nazwy użytkownika, na którego się zalogujemy
3. Publicznego klucza SSH
4. Prywatnego klucza SSH

Pierwsza dwa uzyskamy poprzez wejście do centrum zarządzania instancjami Oracle. Po poprawnym jej utworzeniu powinniśmy w tym miejscu widzieć ją na liście naszych instancji, więc wejdźmy do jej adekwatności [1].

Szukane przez nas informacje (adres IP serwera [2] i nazwa użytkownika [3]) znajdują się w zakładce Instance information w sekcji Instance access po prawej stronie.

Wymagane do uwierzytelniania klucze SSH pobraliśmy już na dysk podczas tworzenia instancji. Mamy już wszystko, więc teraz trzeba tylko to wszystko wrzucić do Termius’a (lub użyć innego programu) i połączyć się z naszym nowiusieńkim VPSem.

Teraz przeprowadzimy podstawową konfigurację serwera. Zaczniemy oczywiście od aktualizacji pakietów. Po jej zakończonej można rozważyć restart serwera.

sudo apt update sudo apt upgrade -y sudo reboot now

Z oczywistych przyczyn zostaniem rozłączeni z serwerem, poczekajmy chwilę na jego ponowne uruchomienie i wznówmy połączenie SSH. Teraz przystąpimy to aktualizacji systemu Ubuntu z wersji 22.04 do 24.04 LTS.

sudo do-release-upgrade

Cały proces jest intuicyjny, więc nie będę go szczegółowo opisywał w tym miejscu. Może kiedyś zrobię o tym oddzielny wpis, o ile faktycznie okaże się, iż w narodzie jest taka potrzeba. o ile potrzebujesz potwierdzenia, iż aktualizacja przebiegła pomyślnie to możesz użyć komendy:

lsb_release -a

Wynik działania polecenia powinien wyglądać mniej więcej tak:

No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 24.04.1 LTS Release: 24.04 Codename: noble

W ramach podstawowej konfiguracji zawsze sprawdzam jeszcze ustawienia autoryzacji poprzez SSH, bo przeważnie nie jest to ustawione tak jak lubię. Dlatego wchodzimy do edytora tekstu i zmieniamy zapisy w pliku sshd_config.

sudo nano /etc/ssh/sshd_config

Musimy w nim znaleźć odpowiednie wiersze i zmienić ich wartość na te poniżej. Uwaga, wskazane linie mogą nie tylko nie być jedna pod drugą, ale także występować w innej kolejności.

PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys PasswordAuthentication no

Zapora sieciowa

Ja korzystając z Oracle używam tak naprawdę trzypoziomowej zapory. Pierwszym poziomem jest zapora w samej infrastrukturze Oracle. Druga to iptables na serwerze, a trzecia to pakiet ufw, który doinstalowuję zawsze we własnym zakresie. Skonfigurujmy je jedna po drugiej.

To jak otwierać porty w infrastrukturze Oracle opisałem w tym wpisie. W turbo skrócie robi się to wchodząc w Virtual Cloud Networks (pamiętam, aby najpierw wybrać odpowiedni Compartment) -> na liście znajdujemy naszą sieć i wchodzimy do jej adekwatności -> z menu Resources po lewej wybieramy Security Lists -> na liście powinna być tylko jedna nazwana Default Security List for…. Interesują nas w tym miejscu Ingress Rules i korzystając z przycisku Add Ingress Rules dodajemy reguły otwierające porty 80, 443, 81, 444, 9443. Robimy to wypełniając formularz dla wszystkich z portów analogicznie do poniższego, w którym zademonstrowałem jak zrobić to dla portu 80.

W ten sposób otworzyliśmy następujące porty:

• 80 – standardowy HTTP dla NGINX Proxy Manager,
• 443 – standardowy HTTPS dla NGINX Proxy Manager,
• 81 – port HTTP dla panelu administracyjnego NGINX Proxy Manager,
• 444 – port HTTPS dla Nextcloud,
• 9443 – port HTTPS dla Portainer.

To wszystko co należy zrobić po stronie Oracle. Kolejnym krokiem jest aktualizacja iptables na serwerze. Jest to taka wewnętrzna tablica z regułami sieciowymi, która określa jaki ruch z i do serwera jest dozwolony, a jaki nie. Przechodzimy na serwer i korzystamy z następujących komend:

sudo su nano /etc/iptables/rules.v4

W ten sposób otworzy nam się edytor tekstu. Odszukujemy wiersz:

(...) -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT (...)

Zaraz po nim dodajemy nowe wiersze o następującej treści:

-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 81 -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 444 -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 9443 -j ACCEPT

Plik rules.v4 zapisujemy i zamykamy poprzez użycie “control + x”, “y” i ENTER. Zostało nam jeszcze skonfigurowanie ostatniej bramy, czyli aplikacji ufw.

sudo apt install ufw sudo ufw disable sudo ufw reset sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow 22 sudo ufw allow 80 sudo ufw allow 443 sudo ufw allow 81 sudo ufw allow 444 sudo ufw allow 9443 sudo ufw enable sudo ufw status verbose

Finalny wynik powinien wyglądać tak:

Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), deny (routed) New profiles: skip To Action From -- ------ ---- 22 ALLOW IN Anywhere 80 ALLOW IN Anywhere 443 ALLOW IN Anywhere 444 ALLOW IN Anywhere 81 ALLOW IN Anywhere 9443 ALLOW IN Anywhere 22 (v6) ALLOW IN Anywhere (v6) 80 (v6) ALLOW IN Anywhere (v6) 443 (v6) ALLOW IN Anywhere (v6) 444 (v6) ALLOW IN Anywhere (v6) 81 (v6) ALLOW IN Anywhere (v6) 9443 (v6) ALLOW IN Anywhere (v6)

Dla pewności należy jeszcze upewnijmy się, iż usługa ufw będzie uruchamiana wraz ze startem systemu (np. po restarcie). Ta opcja powinna się włączyć sama, ale zawsze dobrze sprawdzić to we własnym zakresie. Wchodzimy do pliku konfiguracyjnego ufw:

sudo nano /etc/ufw/ufw.conf

Interesuje nas tutaj, aby zmienna ENABLED była ustawiona na yes:

# Set to yes to start on boot. If setting this remotely, be sure to add a rule # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp' ENABLED=yes

Teraz pozostaje już tylko zrestartować maszynę.

sudo reboot now

Docker i Portainer

Opisałem to szczegółowo w oddzielnym wpisie, więc tutaj przejdę tylko na gwałtownie w ramach przypomnienia.

sudo apt install docker.io -y sudo groupadd docker sudo usermod -aG docker $USER

Docker zainstalowany, więc przechodzimy do stworzenia wolumenu na dane Portainer’a.

docker volume create portainer_data

Następnym krokiem jest już utworzenie odpowiednio skonfigurowanego kontenera.

docker run -d \ -p 9443:9443 \ -v /var/run/docker.sock:/var/run/docker.sock \ -v portainer_data:/data \ --name Portainer \ --restart unless-stopped \ portainer/portainer-ce:latest

Portainer został uruchomiony na porcie 9443, więc teraz musimy odszukać jeszcze raz adres serwera, który wykorzystywaliśmy do połączenia SSH, wejść do przeglądarki i w pasek adresu wpisać:

https://<ip_vpsa_oracle>:9443

Naszym oczom ukaże się bardzo prosty instalator, w którym wystarczy ustawić jedynie login i hasło dla administratora. Na następnej stronie wybieramy przycisk Get Started jako, iż chcemy, aby Portainer używał środowiska znajdującego się na maszynie lokalnej, na której jest uruchomiony. Finalnie zostaniemy przeniesieni do listy dostępnych środowisk, na której będzie jedynie jedno o nazwie local (z ang. lokalne). Aby rozpocząć zarządzanie tym środowiskiem należy po prawej stronie nacisnąć niebieski przycisk Live connect. Poskutkuje to tym, iż po lewej stronie zamiast Environment: None selected pojawią się nam zakładki z opcjami do zarządzania.

Podpięcie domeny przez Cloudflare

1. Logujemy się na Cloudflare.com i naciskamy przycisk Add a domain.
2. Wpisujemy adres posiadanej przez nas domeny, w moim przypadku jest to przykładowe exampleforblog.com. Wybieramy Manually enter DNS records, bo chcemy zaczynać od czystej karty bez zbędnego zgadywania CF jakie rekordy chcemy mieć. Potwierdzamy przyciskiem Continue.
3. Na następnej stronie przewijamy na dół, bo plan (oczywiście jedyny słuszny, czyli darmowy), który nas interesuje jest na samym końcu.
4. Wybieramy plan Free i potwierdzamy przyciskiem Continue.
5. Na kolejnej stronie przewijamy niżej do informacji, które nas interesują.
6. W pierwszej kolejności CF prosi nas o wyłączenie funkcji DNSSEC u naszego dostawcy domen. Nie wszyscy dostawcy włączają to z automatu, ale przykładowo takie OVH chyba właśnie tak robi, więc uznałem, iż warto o tym wspomnieć.
7. Na tej samej stronie, ale niżej, CF listuje nam dwa adresy DNS, do których mamy skierować cały ruch z posiadanej przez nas domeny. Robi się to na stronie dostawcy domeny.
8. Z menu po lewej wybieramy zakładkę DNS i następnie Records. Zaczynamy dodawanie rekordów przyciskiem Add record.
9. W Type zostawiamy A (tak jak jest domyślnie). W pole Name wpisujemy portainer. W IPv4 address podajemy adres naszego serwera VPS od Oracle, goły adres bez żadnych portów, czyli np. 101.102.103.104 (oczywiście zmyśliłem ten adres, więc tutaj wpisz swój). Chcemy, aby ruch był przepuszczany przez CF, więc zostawiamy ustawienie Proxied. TTL nie da się zmienić, więc zostaje Auto. W polu Comment na dole możemy wpisać dowolny komentarz, który pozwoli nam w przyszłości zorientować się o co chodzi i skąd wziął się ten rekord. Napisz po prostu swoimi słowami to co chcesz i do czego będziesz używać tego rekordu. Na koniec pozostaje tylko potwierdzić przyciskiem Save.
10. Pierwszy rekord dodany, ale na potrzeby tego poradnika będziemy potrzebować w sumie trzech, więc dodajemy kolejne korzystając ponownie z przycisku Add record.
11. W ten sposób dodajemy jeszcze analogicznie rekordy dla Name – cloud i nginx. To co zrobiliśmy teraz to utworzyliśmy trzy subdomeny dla domeny macierzystej. Są to odpowiednio portainer.exampleforblog.com, cloud.exampleforblog.com i nginx.exampleforblog.com.
12. Wracamy do menu po lewej i tym razem wybieramy zakładkę SSL/TLS, a z niej Overview. W sekcji podpisanej SSL/TLS encryption naciskamy przycisk Configure.
13. W okienku podpisanym Custom SSL/TLS naciskamy przycisk Select.
14. Zmieniamy opcję z Full na Flexible i potwierdzamy wybór przyciskiem Save.
15. W ramach tej samej zakładki z menu po lewej wybieramy Edge Certificates. Odnajdujemy okienko podpisane Always Use HTTPS i włączamy tą funkcję.
16. Zjeżdżamy niżej, znajdujemy Automatic HTTPS Rewrites i również włączamy tą funkcję.

Gotowe. Możemy się już wylogować z Cloudflare i przejść do następnego kroku.

Alternatywne rozwiązanie z FreeDNS::42 zamiast Cloudflare

To samo co w Cloudflare można uzyskać poprzez skorzystanie np. z FreeDNS::42 lub innego narzędzia tego rodzaju.

1. Zaczynamy od zalogowania się do swojego konta na FreeDNS::42. Przychodzimy do Utwórz strefę.
2. Jako Nazwa strefy podajemy naszą domenę. Jako Typ strefy wybieramy Podstawowe. Naciskamy przycisk Utwórz.
3. Nowa strefa utworzona, więc przechodzimy do zakładki modyfikacji.
4. Przewijamy na dół…
5. … aż znajdziemy sekcję Rekordy (NS) serwerów DNS. Widnieją w niej dwa adresy fns1.42.pl i fns2.42.pl. Na te adresy DNS mamy skierować cały ruch z posiadanej przez nas domeny. Robi się to na stronie dostawcy domeny.
6. Na tej samej stronie przewijamy jeszcze trochę aż do sekcji Rekordy adresów (A), gdzie dodajemy trzy rekordy, które w kolumnie Nazwa będą miały wartości kolejno portainer, nginx i cloud, natomiast w kolumnie IP podajemy trzy razy adres naszego serwera VPS od Oracle.
7. Taką konfigurację finalizujemy przyciskiem Utwórz konfigurację strefy, który znajduje się na samym dole.
8. Na koniec zostanie nam wyświetlone podsumowanie, na którym możemy sprawdzić czy wszystko się zgadza.

NGINX Proxy Manager

NGINX Proxy Manager posłuży do odpowiedniego kierowania ruchem trafiającym do naszego serwera za pośrednictwem domeny, którą dodaliśmy przed chwilą w Cloudflare/FreeDNS::42. Chodzi o to, żeby np. ruch z subdomeny portainer.exampleforblog.com trafił dokładnie na port 9443, czyli tam gdzie uruchomiony jest panel administratora Portainer’a. NGINX Proxy Manager to dużym uproszczeniu taki drogowskaz.

Uruchomienie kontenera z NGINX Proxy Manager’em rozpoczynamy od zalogowania się do panelu administratora Portainer. W sekcji Environments wybieramy local i naciskamy przycisk Live connect. Z menu po lewej wybieramy Stacks. Naciskamy przycisk Add stack. W polu Name wpisujemy nginx_proxy_manager. W sekcji Build method zostawiamy domyślne Web editor. W obszar tekstowy Web editor wklejamy ten gotowy kod:

version: '3.8' services: app: image: 'jc21/nginx-proxy-manager:latest' restart: unless-stopped ports: - '80:80' # Public HTTP Port - '443:443' # Public HTTPS Port - '81:81' # Admin Web Port volumes: - /var/lib/docker/volumes/nginx_proxy_manager/data:/data - /var/lib/docker/volumes/nginx_proxy_manager/letsencrypt:/etc/letsencrypt

Pokrótce go skomentuję. Korzystamy z obrazu jc21/nginx-proxy-manager, który zostanie pobrany z Docker Hub. Kontener będzie automatycznie restartowany po każdym zatrzymaniu, chyba iż sami manualnie go zatrzymamy. Będzie używać portów 80 (HTTP), 443 (HTTPS) i 81. Pod tym ostatnim dostępny będzie panel administratora. To właśnie na niego wskażemy subdomeną nginx.exampleforblog.com. Tworzymy dwa wolumeny, którymi wyciągniemy z kontenera foldery /data (dane dot. konfiguracji) i /etc/letsencrypt, czyli miejsce, w którym zapisane będą certyfikaty SSL.

Po wklejeniu tego kodu kilka więcej musimy robić, bo wystarczy tylko utworzyć tak skonfigurowany kontener korzystając z przycisku Deploy the stack znajdującego się w sekcji Actions na samym dole. Robienie tego z poziomu Stacks ma tą zaletę, iż za jednym razem załatwiamy wszystko, czyli tworzymy kontener oraz wolumeny potrzebne do jego działania.

Przejdźmy teraz do panelu administratora NGINX Proxy Manager’a. Wchodzi się tam przez przeglądarkę wpisując w pasek adresu:

https://<ip_vpsa_oracle>:81

Przywita nas od razu formularz logowania. Ale jaki jest login i hasło? Na pomoc przychodzi nam dokumentacja, w której podane jest, iż kontener tworzony jest z domyślnymi poświadczeniami, które po pierwszym logowaniu jesteśmy zmuszeni zmienić. Są to:

Email: admin@example.com Password: changeme

Logujemy się przy ich pomocy i od razu tworzymy nowego administratora na podstawie już wprowadzonych przez siebie danych. Przechodzimy do zakładki Hosts, która znajduje się na pasku na górze, i wybieramy Proxy Hosts. Korzystając z przycisku Add Proxy Host dodajemy pierwszego. W pole Domain Names wpisujemy portainer.exampleforblog.com (oczywiście exampleforblog.com zamień na swoją domenę). W Scheme wybieramy https. W Forward Hostname / IP wpisujemy lokalny adres IP swojego serwera. Aby go poznać potrzebujemy zainstalować net-tools:

sudo apt install net-tools

I użyć polecenia:

ifconfig

Poszukiwany adres będzie znajdował się w sekcji enp0s6. Tak wygląda wycinek z wyniku działania komendy ifconfig.

enp0s6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000 inet 10.0.0.195 netmask 255.255.255.0 broadcast 10.0.0.255 inet6 ... prefixlen 128 scopeid 0x0<global> inet6 ... prefixlen 64 scopeid 0x20<link> ether 02:00:17:06:21:40 txqueuelen 1000 (Ethernet) RX packets 335922 bytes 763693420 (763.6 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 301753 bytes 418933520 (418.9 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Adres, którego szukamy to w moim przypadku 10.0.0.195 (u Ciebie prawie na pewno będzie inny). Pozostaje nam jeszcze wpisać 9443 w polu Forward Port. Prawidłowo wypełniony formularz w moim wypadku wygląda tak:

Ale to nie koniec, bo musimy jeszcze przeskoczyć z zakładki Details do SSL, gdzie z menu rozwijanego podpisanego SSL Certificate wybieramy Request a new SSL Certificate. Do tego zaznaczamy opcję Force SSL oraz I Agree to the Let’s Encrypt Terms of Service.

Teraz możemy już potwierdzić przyciskiem Save. Robimy to samo analogicznie jeszcze dwa razy dla dwóch pozostałych subdomen, które utworzyliśmy w Cloudflare.

• dla nginx.exampleforblog.com podajemy port 81
• dla cloud.exampleforblog.com podajemy port 444

Nextcloud i MariaDB

Ostatnie co nam pozostało to stworzenie kontenera Nextcloud, dla którego bazą danych będzie MariaDB uruchomiona w oddzielnym, ale sprzężonym kontenerze. Zrobimy to w sposób analogiczny do tego jak robiliśmy to w przypadku NGINX Proxy Manager, czyli poprzez Stacks w Portainer. A zatem wchodzimy w Stacks i naciskamy przycisk Add stack. Jako Name podajemy nextcloud, a w Web editor wklejamy poniższy gotowy kod:

version: '2' services: db: image: mariadb:latest restart: unless-stopped command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW volumes: - /var/lib/docker/volumes/Nextcloud_Database:/var/lib/mysql environment: - MYSQL_ROOT_PASSWORD=<hasło_roota_bazy_danych> - MYSQL_PASSWORD=<hasło_użytkownika_dla_nextcloud> - MYSQL_DATABASE=nextcloud - MYSQL_USER=nextcloud app: image: lscr.io/linuxserver/nextcloud:latest restart: unless-stopped ports: - 444:443 links: - db volumes: - /var/lib/docker/volumes/Nextcloud_Application/config:/config - /var/lib/docker/volumes/Nextcloud_Application/data:/data environment: - MYSQL_PASSWORD=<hasło_użytkownika_dla_nextcloud> - MYSQL_DATABASE=nextcloud - MYSQL_USER=nextcloud - MYSQL_HOST=db - PUID=1000 - PGID=1000 - TZ=Europe/Warsaw

W tym kodzie tworzymy tak naprawdę tandem składający się z dwóch kontenerów. Pierwszy z nich to baza danych. Z kolei drugi to nasza chmura Nextcloud. Co interesujące dla bazy danych nie przypisałem żadnego portu, a mogłem, bo w przyszłości mógłbym chcieć z niej skorzystać. Nie jest to wielki problem, bo w później można to zmodyfikować. Natomiast dla Nextcloud przypisałem port 444, bo 443 jest już zajęty do obsługi NGINX Proxy Manager’a, ale to zostało już przez nas załatwione odpowiednim przekierowaniem na etapie konfiguracji NGINX Proxy Manager’a. o ile chodzi o obraz Dockera to wykorzystałem lscr.io/linuxserver/nextcloud, a nie oficjalny obraz, który też jest dostępny na Docker Hub. Wszystko rozchodzi się o to, iż obraz od linuxserver (chyba) jako pierwszy miał wsparcie dla architektury ARM i po prostu używam go już od dawna. Do tego mam średnie doświadczenia z tym oficjalnym, więc po prostu wolę ten i polecam go. Zauważ, iż w kodzie są dwa fragmenty <hasło_roota_bazy_danych> i <hasło_użytkownika_dla_nextcloud>, wpisz w ich miejsce wymyślone przez siebie hasła. Tak sparametryzowany Stack tworzymy potwierdzając przyciskiem Deploy the stack i gotowe.

Aby dostać się do naszej świeżo stworzonej chmury nie musimy już bawić się w żadne adresy IP, bo wystarczy, iż po prostu wklepiemy w pasek przeglądarki adres cloud.exampleforblog.com. Pozostaje nam już tylko utworzenie konta administratora i finalizacja instalacji. Podczas instalacji może wyniknąć konieczność podania jeszcze raz danych dostępowych do bazy danych MariaDB, bo z nieznanych mi powodów co jakiś czas zdarza się, iż nie są one prawidłowo zapisane w kontenerze podczas jego tworzenia. Nie jest to wielki problem, bo wystarczy podczas instalacji Nextcloud rozwinąć menu z ustawieniami zaawansowanymi, wybrać MariaDB i wypełnić cztery pola danymi, które podaliśmy podczas tworzenia Stack’a w Web editor’ze.

MYSQL_PASSWORD=<hasło_użytkownika_dla_nextcloud> MYSQL_DATABASE=nextcloud MYSQL_USER=nextcloud MYSQL_HOST=db

O Nextcloud pisałem sporo w dwóch wpisach, więc podlinkuję je tutaj, bo mogą się przydać:

• Nextcloud – prywatna chmura na pliki
• Portainer – GUI dla Docker’a

Na koniec jeszcze jedna rzecz, z którą każdy prawdopodobnie będzie miał problem, a jest nią taki komunikat:

Rozwiązanie tego problemu jest stosunkowo proste, ale znalezienie go już nie do końca, bo trzeba trochę poszukać w dokumentacji. Mogli to zrobić zdecydowanie bardziej intuicyjnie… Na szczęście macie mnie, czyli gościa, który odwalił już całą robotę i za chwile przedstawi gotowe i zwięzłe rozwiązanie. Otwieramy w edytorze tekstowym plik config.php, o którym mowa w komunikacie.

sudo su nano /var/lib/docker/volumes/Nextcloud_Application/config/www/nextcloud/config/config.php

Odnajdujemy w nim sekcję trusted_domains i wypełniamy ją analogicznie do tego:

(...) 'trusted_domains' => array ( 0 => 'localhost', 1 => 'cloud.exampleforblog.com', ), (...)

Oczywiście zamiast cloud.exampleforblog.com należy podać swoją subdomenę, którą konfigurowaliśmy wcześniej. Teraz odśwież stronę w przeglądarce, a dostęp będzie już możliwy.

Zamykanie portów (aktualizacja 07-10-2024)

Na koniec możemy jeszcze pozamykać porty 81, 444 i 9443 na poziomie zapory Oracle i iptables. Nie jest to jakieś konieczne zabezpieczenie, ale na pewno można nazwać to dobrą praktyką. Usuwa się je analogicznie tak jak je się dodawało, więc nie będę tego opisywał. Dopowiem jednak, iż takie działanie sprawi, iż Portainer, NGINX Proxy Manager i Nextcloud będą dalej dostępne z zewnątrz, ale jedynie przez odpowiednie subdomeny, które do nich przypisaliśmy w NGINX Proxy Manager’ze. Nie będzie natomiast możliwe dostanie się do np. Portainer’a poprzez wpisanie https://<ip_vpsa_oracle>:9443. Porty muszą jednak zostać otwarte na poziomie ufw, bo jak tam je zamkniemy to choćby i przez NGINX nie będzie możliwości dostępu do zasobu z zewnątrz.

Podsumowanie

Znowu wyszedł mi straszny tasiemiec, ale wierzę, iż to lubicie. W tym wpisie zawarty jest kawał porządnego mięska. Liczę, iż komuś się to przyda. o ile Tobie się przydało to napisz do mnie w dowolny możliwy sposób (komentarz poniżej, Mastodon itd.) i pochwal się swoją nową i co najważniejsze w pełni darmową chmurą. Poleć ten sposób znajomym, niech i oni na tym skorzystają. W przypadku napotkania jakichkolwiek problemów także śmiało pisz. Obiecuję, iż postaram się pomóc najlepiej jak tylko będę mógł. Powodzenia!

Aha i na koniec, zauważ, iż tak stworzone środowisko jest w zasadzie idealną podwaliną do tego, żeby na tym serwerze stawiać różne inne wartościowe usługi. Myślę, iż wrócę do tego tematu jeszcze nie raz w kolejnych wpisach. Jak masz jakiś interesujący pomysł jak można wykorzystać taką maszynę to chętnie o nim przeczytam!