Develpoment za pmocą dockera ciąg dalszy

Hej!

Siedząc ostatnio w projekcie komercyjnym sealcodu zacząłem się zastanawiać czy nie można by naszego developmentu w 100% pociągnąć za pomocą dockera. Co mam na myśli?

Na ten moment możemy wywoływać komndy npma z w dockerze za pomocą ./npm.sh. Jednak gdy sprobujemy odpalic watcha to dostaniemy informacje ze tmux nie jest zainstalowany na tym obrazie

 ➜ xd (master) ✅ ./npm.sh run watch
+ docker-compose run --rm --service-ports test npm run watch

> sealious-app@0.1.0 watch
> multiple-scripts-tmux "npm run typecheck:back -- --watch"  "SEALIOUS_PORT=$SEALIOUS_PORT SEALIOUS_BASE_URL=$SEALIOUS_BASE_URL nodemon --enable-source-maps ." "npm run build -- --watch" "npm run typecheck:front -- --watch"

/bin/sh: 1: tmux: not found

Z tego co pamietam to poza npmowa paczka potrzebujemy tez zainstalowac samgeo tmuxa?

Często też były problemy z tym kto jakiej wersji nodea używa.

Pomysł na to mam taki, żebyśmy stworzyli i opublikowali (albo na dockerhubie albo zrobic wlasne repo do obrazow dockerowych) obraz specjalnie napisany do selcodowego developmentu. Ustalałby on wersje nodea z góry oraz miał zainstalowane wszystko co potrzebne czyli chociażby tmuxa. Można by też pójść o krok dalej i zainstalować tam arcanista, ale wymyśliłem to teraz jak piszę i może to nie jest najlepszy pomysł bo trzebaby go konfigurować przy starcie nowego projektu od nowa (choć rozwiązałoby problem z updatetami arcanista ktore sie tez od czasu do czsau zdarzaly).
Gdy już byśmy mieli taki obraz to po prostu suealoius-playground moglby go uzywac w pliku docekr-comopse i npm.sh by w nim odpalal wszysktie npmowe komendy

Wydaje mi sie ze takie rozwiazanie ma kilka polusow. Przedewszystkim jeszcze bardzije zmniejszamy liczbe potencjalnyhc problemow akie moga napotkac siweze osoby. Caly onboarding sprowadzałby się do zainstaluj arcanista, dodaj klucz sh, sklonuj repo, docker-compose up -d i używaj npm.sh. Znika wiele probelmow z instalowaniem paczek oraz tym kto jakiej wersji nodea uzywa.
Druga zaleta to zwiekszylaby sie liczba osob ktore potencjalnie moglyby brac udzial w projektach. Do tej pory z tego co pamietam z stakciem sealcodowym mialy problemy osoby uzywajace maca lub windowsa. Wydaje mi sie ze uzywanie dockera juz rozwiazuje probelm maca i z wyczytalme tez ze docker comose jest instalowany na windowsie wraz z docekr desktop

If you installed Docker Desktop/Toolbox for either Windows or Mac, you already have Docker Compose! Play-with-Docker instances already have Docker Compose installed as well. If you are on a Linux machine, you will need to install Docker Compose.

Oznaczałoby to, że moglibyśmy dodać do sealious-plaground podobny skrypt do npm.sh np. npm.cmd i osoby z windowsem moglyby bez problemu brac udzial w tych projektach,

Co myślicie na ten temat i czy widzicie jakies potencjalne niedopatrzenia?

Nooo rozwiązałoby to trochę problemów. Ja osobiście wolę odpalać aplikację natywnie, bo jest lżej - ale wiem, że nasze środowiska się różnią i są rożne potrzeby.

Podejrzewam, że poszerzenie zdolności naszego dockerowego obrazu o odpalanie npm run watch z tmuxem nie przeszkodzi mi nadal w odpalaniu aplikacji natywnie. O ile zostanie furtka na bezdockerowe npm run watch - nie widzę przeciwskazań, aby coś takiego zrobić :slight_smile: Dałbym zielone światło na merge’a.

Nie wiem, czy jest potrzeba publikować obraz w jakimś repozytorium. Chyba sam przepis na obraz budowany docker-compose build by wystarczył. Ale może @Jakski ma jakieś porady/przestrogi tutaj? :smiley:

Nie wiem jak wygląda konfiguracja w nowszych projektach, więc będę traktował gałąź dev z repozytorium Sealious · sealious jako punkt odniesienia.

Nie ma potrzeby. Dodatkowo test.dockerfile traktuje UID i GID użytkownika jako parametry, aby można go było w razie potrzeby lokalnie zbudować z innymi wartościami. Jeśli zostałby opublikowany obraz, a lokalnie ktoś miałby użytkownika z UID 1001 zamiast domyślnego 1000, to doszłoby prawdopodobnie do problemu z uprawnieniami. Rzadki scenariusz, ponieważ domyślnie pierwszy użytkownik na chyba każdej dystrybucji dostaje podczas instalacji UID 1000, ale warto o tym pamiętać.

Warto, aby wypowiedział się tu jakiś użytkownik MacOS-a. Docker na MacOS cierpi bardzo mocno na wydajności woluminów udostępnianych z lokalnego systemu plików, tzw. bind mounts. Spotkałem się już z obejściami polegającymi na dostawianiu obok/w Docker procesu synchronizującego pliki, aby pominąć niewydajne udostępnianie katalogów.

1 Like

Oj, no kiedyś ktoś u nas robił projekt na maku w dockerze i działało tak wolno, że zdecydował się odpalić ten projekt w dockerze na linuksie wewnątrz maszyny wirtualnej w maku - i działało 20x szybciej XD Ale może już naprawili…

Zastanawiam się, czy problemu z wersją node’a nie będzie łatwiej obejść po prostu za pomocą .nvmrc: GitHub - nvm-sh/nvm: Node Version Manager - POSIX-compliant bash script to manage multiple active node.js versions

Myślę, że dodanie tego pliku to też zawsze pomoc dla nowych osób. Myślę, że najlepszym sposobem będzie tak jak powiedziałeś przygotować obraz po to, żeby watch mógł być odpalany w dockerze jeśli ktoś chce, a jeśli nie to lokalnie nadal powinien działać. No i dodanie .nvmrc rozwiąże ten problem dodatkowo na lokalnych setupach jak ktoś tak woli. Mogę jak będę miał chwilkę przygotować diffa z watchem działającym lokalnie oraz w dockerze

2 Likes

Super, jestem za!