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

Cesta URL: co se děje, než se načte webová stránka

Když do adresního řádku prohlížeče napíšete webovou adresu a stisknete Enter, spustí se fascinující řetězec procesů, které propojují váš počítač s celým světem. Od překladu doménového jména na IP adresu, přes navázání šifrovaného spojení, až po vykreslení každého pixelu na obrazovce - to všechno se odehraje během zlomků sekundy. Pojďme se podívat, co se mezitím děje pod kapotou webu.

Stav SIMD v Rustu v roce 2025

Různé
Komentáře: 1
SIMD - neboli Single Instruction, Multiple Data - znamená, že procesor může jednou instrukcí zpracovat více datových prvků najednou. Typicky to znamená, že místo sčítání dvou čísel přičtete dvě sady čísel paralelně. To může přinést výrazné zrychlení například při zpracování obrazu, audia nebo numerických výpočtů. Pokud již SIMD znáte, tato tabulka je vše, co budete potřebovat. A pokud s SIMD teprve začínáte, tabulku pochopíte do konce tohoto článku