Přejít k navigační liště

Zdroják » Různé » Brew a vývoj s lokálním PHP a DB i Adminerem v Dockeru

Brew a vývoj s lokálním PHP a DB i Adminerem v Dockeru

Články Různé

Provoz Brew, Dockeru, PHP a databází na OSX.

Text vyšel původně na webu autora.

Brew: install, upgrade a cleanup

Brew je mým společníkem od dob, co jsem na OSX. Pomáhá mi s instalací balíčků.

Nainstalovat PHP 7.3? No problema!

brew install php@7.3

Aktualizovat Node.js nebo yarn?

brew install nodejs yarn
brew upgrade

A co desktop aplikace? Na to je brew cask.

brew cask install transmission
brew cask install vlc
brew cask install google-chrome
brew cask install now

Jasně, kupa aplikací lze nainstalovat pekně přes dmg, ale pak je otrava je aktualizovat. S brew cask? Hračka!

brew cask upgrade

Po pořádné práci je potřeba si uklidit. Nechceme přece, aby se nám po systému válely staré a nepoužívané aplikace.

brew cleanup

Po roce používání a nečištění to pak dopadá takto:

brew cleanup

Vývoj s lokálním PHP a DB i Adminerem v Dockeru

Zvykl jsem si používat při vývoji lokální PHP a Adminer + DB v Dockeru.

Už skoro 2 roky vyvíjím PHP aplikace bez Dockeru. Myslím tím, že mam nainstalované PHP přes Brew lokálně.

To, že je Docker na OSX pomalý, není žádná novinka, každý kdo s Dockerem někdy na OSX pracoval na to jistě narazil. Dá se to potunit ruznými způsoby, já osobně jsem si nainstaloval PHP lokálně (přes brew) a nemůžu si to vynachválit.

No jo, ale statických projektů tolik není, co s databází? Tu naopak v Dockeru spouštím.

Je libo MariaDB 10.4?

docker run \
	-it \
	-d \
	-p 3306:3306 \
	--name xproject_mariadb \
	-e MYSQL_ROOT_PASSWORD=rootpw \
	-e MYSQL_DATABASE=project \
	-e MYSQL_USER=project \
	-e MYSQL_PASSWORD=project \
	mariadb:10.4

Je libo Postgres 11?

docker run \
	-it \
	-d \
	-p 5432:5432 \
	--name xproject_postgres \
	-e POSTGRES_PASSWORD=project \
	-e POSTGRES_USER=project \
	postgres:11

Databázi bychom měli, ještě do ní budeme koukat přes Adminer. Mrkněte na image dockette/adminer, je fakt tenkej.

docker run \
	-it \
	-d \
	-p 9999:80 \
	--link xproject_adminer \
	--name xproject_adminer \
	dockette/adminer:dg

Na OSX je pak vychytávka v podobě host.docker.internal, která funguje jako hostname. Kontejner s Adminerem se pak dokáže spojit s hostem a jelikož máme MariaDB kontejner vystavený na portu 3306, tak se k němu dokáže Adminer spojit.

Dockette Adminer - host.docker.internal

A k tomu všemu jsem si oblíbil Makefile. Proč to celé nemít zautomatizované?

loc-mariadb: loc-mariadb-stop
	docker run -it -d -p 3306:3306 --name xproject_mariadb -e MYSQL_ROOT_PASSWORD=rootpw -e MYSQL_DATABASE=project -e MYSQL_USER=project -e MYSQL_PASSWORD=project mariadb:10.4

loc-mariadb-stop:
	docker stop xproject_mariadb || true
	docker rm xproject_mariadb || true

loc-adminer: loc-adminer-stop
	docker run -it -d -p 9999:80 --link xproject_mariadb --name xproject_adminer dockette/adminer:dg

loc-adminer-stop:
	docker stop xproject_adminer || true
	docker rm xproject_adminer || true

loc-dev:
	NETTE_DEBUG=1 php -S 0.0.0.0:8000 -t www

loc-webpack:
	npm run dev

Já realně pracuji na 1 projektu naráz, ale pokud často přepínáte, můžete si udělat jednu společnou DB pro všechny projekty a nebo mít různé porty pro různé DB.

Komentáře

Odebírat
Upozornit na
guest
4 Komentářů
Nejstarší
Nejnovější Most Voted
Miroslav Hančík

Rychlost/pomalost Dockeru na OSX se řeší velmi jednoduše, v docker-compose(.override).ym pomocí cached:

services:
   app:
     volumes:
       - '.:/app:rw,cached'

Co je horší, tak na Windows je to pořád pomalé. Kolegové to většinou řeší virtualizací Debianu, což sice funguje, ale.. :)

Makefile je bezva, trochu se divím, že si nezjednodušíte život použitím docker-compose. Přijde mi trochu matoucí, že některé cíle spouští něco uvnitř kontejneru a něco přímo na hostovi. Já doiteroval do něčeho na tento způsob (zjednodušené; předpokládám docker-compose.yml (build only) + docker-compose.override.yml (dev) + docker-compose.production.stack.yml (konfigurace pro Docker Swarm deploy)).

dev:
   docker-compose up 
build: 
   docker-compose build 
rebuild:
   docker-compose build --no-cache
destroy:
   docker-compose down -v 
test:
   docker-compose -f docker-compose.yml -f docker-compose.test.yml up -d
   docker-compose exec app composer phpstan 
Karel Pávek

Volume :cached určitě pomůže, ale u větších projektů už ten výkon stejně degraduje (bavíme se o velkém vendoru, node_modules a spoustě projektových souborů). Nejrychlejší co máme zatím odzkoušeno na MacOS je nfs server. Ale i přesto je Linux a Docker stejně rychlejší, než na MacOS. Nebo lokální PHP :-), které zase ztrácí výhody virtualizace jako např. distribuce homogenního prostředí mezi vývojáře.

Honza

cached některé problémy řeší, některé přináší. Nicméně výkon je pořád tristní, u mě cca 8x pomalejší než nativně instalované PHP

Miroslav Hančík

Můžu se zeptat, co za problémy Vám to přineslo? Ať vím na co si případně dát pozor.
Zatím jsem se ničím konkrétním nesetkal, projeky máme většinou PHP + NodeJS. Díky

Odysseus: PewDiePie vydal open-source AI workspace, který běží na vašem vlastním hardwaru

AI
Komentáře: 0
Felix Kjellberg, youtuber se 110 miliony odběratelů, strávil rok učením se programovat a fine-tuningem vlastních AI modelů. Výsledkem je Odysseus – bezplatný, open-source workspace pro práci s umělou inteligencí, který neposílá žádná data do cloudu. Projekt má týden, přes 61 000 hvězdiček na GitHubu a znovu otevírá otázku, komu vlastně patří váš digitální kontext.

Když Git už nestačí: jak izolovat databázový stav pro pokusy AI agentů

Gitová větev vývojářům oddělí kód, ale databáze často zůstává společná. U AI agentů je to slabé místo: rychle spouštějí migrace, mění data a zkoušejí víc cest najednou. Databázová větev jim dá vlastní pracovní prostor, jenže tím práce nekončí. Ještě je potřeba řešit citlivá data, oprávnění, životnost větve i zbytek stavu aplikace.

GitHub vyhrál pohodlím. Stejné pohodlí dnes ztěžuje odchod

GitHub kdysi působil jako přesný opak SourceForge: rychlý, přehledný a přirozený. Dnešní projekt na něm ale často nemá jen kód. Má tam issues, pull requesty, CI, balíčky, bezpečnostní pravidla i AI agenty. Lock-in nevzniká tím, že by nešel odnést Git repozitář, ale tím, že se běžný provoz týmu postupně přesune do jedné platformy.