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

GPUI Component: moderní Rust GUI komponenty pro cross-platform desktop aplikace

Různé
Komentáře: 0
GPUI Component je open-source Rust knihovna rozšiřující framework GPUI o více než 60 moderních, nativních a multiplatformních UI komponent. Staví na deklarativním přístupu, stateless renderování a jednoduchém API inspirovaném Reactem či Yew. Díky optimalizovanému výkonu, podpoře témat a flexibilním layoutům umožňuje rychlý vývoj desktopových aplikací, jako je například trading nástroj Longbridge Pro. Knihovna je licencována pod Apache 2.0 a dostupná na GitHubu.

Vitest 4.0 – nové vizuální testování, lepší debugging a stabilní Browser Mode

Nová verze Vitest 4.0 posouvá hranice testování webových aplikací. Přináší stabilní běh testů přímo v prohlížeči, podporu vizuálního regresního testování i chytřejší práci s lokátory a typováním. Vývojáři tak získávají robustnější, rychlejší a přehlednější nástroje pro zajištění kvality UI i logiky aplikací.