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
Inline Feedbacks
Zobrazit všechny komentáře
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

Hermes místo OpenClaw?

AI
Komentáře: 2
Většina AI agentů v roce 2026 vám nabízí pohodlí výměnou za kontrolu — běží na cizí infrastruktuře, ukládají vaše data neznámo kam a fungují jen tak, jak je jejich tvůrci navrhli. Hermes od Nous Research jde opačným směrem: je open-source, nainstalujete si ho na vlastní server za pár dolarů měsíčně, připojíte k libovolnému LLM a necháte ho, aby si sám psal vlastní schopnosti podle toho, co od něj potřebujete. Výsledek? Agent, který skutečně patří vám a po pár týdnech používání rozumí vašemu setupu lépe než kterýkoli komerční asistent. Podívejme se, co Hermes umí, jak ho rozjet a pro koho dává smysl.

Robots.txt nestačí. AI crawleři mění, jak weby chrání obsah

Robots.txt zůstává základní signál pro slušné crawlery, ale už neumí popsat hlavní problém: stejný veřejný obsah může sloužit klasickému vyhledávání, AI odpovědím, tréninku modelů i načtení na pokyn uživatele. Provozovatel webu proto musí oddělit účel přístupu, ověřovat identitu botů, měřit dopad na infrastrukturu a u hodnotného obsahu řešit i vynucení pravidel mimo samotný robots.txt.

Jak funguje WordPress Cron a proč občas selhává

„Cron mi nějak neběhá." Klasická věta, která ve WordPress světě může znamenat cokoli od špatně nastavené WP_SITEURL, přes loopback zablokovaný Cloudflarem, až po fatal error v callbacku, který nechal viset transient doing_cron. WP-Cron totiž není skutečný scheduler — je to pseudo-cron závislý na návštěvnosti webu a HTTP loopbacku, se všemi pastmi, které si dokážete představit. Tenhle článek je hloubkový průchod jeho vnitřnostmi: co se reálně děje při spawn_cron(), kde vznikají race conditions, proč selhává a čím ho v produkci nahradit.