Drukowana wersja tematu

Kliknij tu, aby zobaczyć temat w orginalnym formacie

Forum PHP.pl _ Frameworki _ [LR] Docker lokalnie działa wolno

Napisany przez: markonix 4.12.2017, 17:20:33

Mam problem z wydajnością dockera na komputerze lokalnym. Docker odpalony na natywnej wirtualnej maszynie (Windows 10 Professional).
Generalnie ta sama aplikacja działa wolniej niż na przeciętnym dedyku, wydawałoby się, że lokalnie odpada sieć więc powinno to działać szybciej.
Ogólne działanie pół biedy ale gdy dłużej nic nie robię i odświeżam stronę to potrafi czasem 10 sekund mielić, słyszę wtedy że komputer pracuje.

W Debugbar:
Booting (3.96s)
Application (3.54s)
ale to szczerze mi mało mówi :/

Gdzie szukać przyczyny? Gdzieś znajdę jakieś logi (log nginx, który widzę live działa też z tym lagiem więc nic mi nie mówi). Mam wrażenie, że chodzi coraz ciężej (więcej kodu) ale żeby aż tak? Mam dość dobry procesor, a dysk na PCI Express x4 3 więc szybszy niż standardowy SSD..
Równolegle działający phpmyadmin śmiga aż miło.
Nie sądzę aby to była wina Windowsa zwłaszcza, że ktoś ma podobny problem z jabłku:
https://github.com/laradock/laradock/issues/1227

Napisany przez: nospor 4.12.2017, 17:29:12

Tak z czystej ciekawosci: ty odpalasz te wszystkie kontenery jakie sa domyslnie w laradoc?

Napisany przez: markonix 4.12.2017, 18:07:11

Kontenery odpalam 4 (workspace, nginx, mysql, php) + 1 phpmyadmin opcjonalnie.

Konfiguracja tego co odpalam:

Kod

############################
# General Setup
############################

### Application Path
# Point to your application code, will be available at `/var/www`.

APPLICATION=../

### Data Path:
# For all storage systems.

DATA_SAVE_PATH=~/.laradock/data

### PHP version
# Applies to the Workspace and PHP-FPM containers (Does not apply to HHVM)
# Accepted values: 71 - 70 - 56

PHP_VERSION=71

### PHP interpreter
# Accepted values: hhvm - php-fpm

PHP_INTERPRETER=php-fpm

############################
# Containers Customization
############################

### WORKSPACE ################################################################################
##########################

WORKSPACE_INSTALL_XDEBUG=false
WORKSPACE_INSTALL_LDAP=false
WORKSPACE_INSTALL_SOAP=true
WORKSPACE_INSTALL_MONGO=false
WORKSPACE_INSTALL_PHPREDIS=false
WORKSPACE_INSTALL_MSSQL=false
WORKSPACE_INSTALL_NODE=false
WORKSPACE_INSTALL_YARN=false
WORKSPACE_INSTALL_DRUSH=false
WORKSPACE_INSTALL_DRUPAL_CONSOLE=false
WORKSPACE_INSTALL_AEROSPIKE=false
WORKSPACE_INSTALL_V8JS=false
WORKSPACE_COMPOSER_GLOBAL_INSTALL=false
WORKSPACE_INSTALL_WORKSPACE_SSH=false
WORKSPACE_INSTALL_LARAVEL_ENVOY=false
WORKSPACE_INSTALL_LARAVEL_INSTALLER=false
WORKSPACE_INSTALL_DEPLOYER=false
WORKSPACE_INSTALL_LINUXBREW=false
WORKSPACE_INSTALL_MC=false
WORKSPACE_INSTALL_SYMFONY=false
WORKSPACE_INSTALL_PYTHON=false
WORKSPACE_INSTALL_IMAGE_OPTIMIZERS=false
WORKSPACE_INSTALL_IMAGEMAGICK=false
WORKSPACE_INSTALL_TERRAFORM=false
WORKSPACE_INSTALL_DUSK_DEPS=false
WORKSPACE_PUID=1000
WORKSPACE_PGID=1000
WORKSPACE_CHROME_DRIVER_VERSION=2.32
WORKSPACE_NODE_VERSION=stable
WORKSPACE_YARN_VERSION=latest
WORKSPACE_TIMEZONE=UTC
WORKSPACE_SSH_PORT=2222

### PHP_FPM ################################################################################
############################

PHP_FPM_INSTALL_XDEBUG=false
PHP_FPM_INSTALL_MONGO=false
PHP_FPM_INSTALL_MSSQL=false
PHP_FPM_INSTALL_SOAP=true
PHP_FPM_INSTALL_ZIP_ARCHIVE=true
PHP_FPM_INSTALL_BCMATH=false
PHP_FPM_INSTALL_PHPREDIS=false
PHP_FPM_INSTALL_MEMCACHED=false
PHP_FPM_INSTALL_OPCACHE=false
PHP_FPM_INSTALL_EXIF=false
PHP_FPM_INSTALL_AEROSPIKE=false
PHP_FPM_INSTALL_MYSQLI=false
PHP_FPM_INSTALL_TOKENIZER=false
PHP_FPM_INSTALL_INTL=false
PHP_FPM_INSTALL_GHOSTSCRIPT=false
PHP_FPM_INSTALL_LDAP=false
PHP_FPM_INSTALL_SWOOLE=false
PHP_FPM_INSTALL_IMAGE_OPTIMIZERS=false
PHP_FPM_INSTALL_IMAGEMAGICK=true

### NGINX ################################################################################
##############################

NGINX_HOST_HTTP_PORT=80
NGINX_HOST_HTTPS_PORT=443
NGINX_HOST_LOG_PATH=./logs/nginx/
NGINX_SITES_PATH=./nginx/sites/
NGINX_PHP_UPSTREAM_CONTAINER=php-fpm
NGINX_PHP_UPSTREAM_PORT=9000

### APACHE ################################################################################
#############################

APACHE_HOST_HTTP_PORT=80
APACHE_HOST_HTTPS_PORT=443
APACHE_HOST_LOG_PATH=./logs/apache2
APACHE_SITES_PATH=./apache2/sites
APACHE_PHP_UPSTREAM_CONTAINER=php-fpm
APACHE_PHP_UPSTREAM_PORT=9000
APACHE_PHP_UPSTREAM_TIMEOUT=60

### MYSQL ################################################################################
##############################

MYSQL_VERSION=8.0
MYSQL_DATABASE=default
MYSQL_USER=default
MYSQL_PASSWORD=secret
MYSQL_PORT=3306
MYSQL_ROOT_PASSWORD=root
MYSQL_ENTRYPOINT_INITDB=./mysql/docker-entrypoint-initdb.d

### REDIS ################################################################################
##############################

REDIS_PORT=6379

### Percona ################################################################################
############################

PERCONA_DATABASE=homestead
PERCONA_USER=homestead
PERCONA_PASSWORD=secret
PERCONA_PORT=3306
PERCONA_ROOT_PASSWORD=root
PERCONA_ENTRYPOINT_INITDB=./percona/docker-entrypoint-initdb.d

### MSSQL ################################################################################
##############################

MSSQL_DATABASE=homestead
MSSQL_PASSWORD=yourStrong(!)Password
MSSQL_PORT=1433

### MARIADB ################################################################################
############################

MARIADB_DATABASE=default
MARIADB_USER=default
MARIADB_PASSWORD=secret
MARIADB_PORT=3306
MARIADB_ROOT_PASSWORD=root
MARIADB_ENTRYPOINT_INITDB=./mariadb/docker-entrypoint-initdb.d

### POSTGRES ################################################################################
###########################

POSTGRES_DB=default
POSTGRES_USER=default
POSTGRES_PASSWORD=secret
POSTGRES_PORT=5432

### RABBITMQ ################################################################################
###########################

RABBITMQ_NODE_HOST_PORT=5672
RABBITMQ_MANAGEMENT_HTTP_HOST_PORT=15672
RABBITMQ_MANAGEMENT_HTTPS_HOST_PORT=15671
RABBITMQ_DEFAULT_USER=guest
RABBITMQ_DEFAULT_PASS=guest

### ELASTICSEARCH ################################################################################
######################

ELASTICSEARCH_HOST_HTTP_PORT=9200
ELASTICSEARCH_HOST_TRANSPORT_PORT=9300

### KIBANA ################################################################################
#############################

KIBANA_HTTP_PORT=5601

### MEMCACHED ################################################################################
##########################

MEMCACHED_HOST_PORT=11211

### BEANSTALKD CONSOLE ################################################################################
#################

BEANSTALKD_CONSOLE_BUILD_PATH=./beanstalkd-console
BEANSTALKD_CONSOLE_CONTAINER_NAME=beanstalkd-console
BEANSTALKD_CONSOLE_HOST_PORT=2080

### BEANSTALKD ################################################################################
#########################

BEANSTALKD_HOST_PORT=11300

### SELENIUM ################################################################################
###########################

SELENIUM_PORT=4444

### MINIO ################################################################################
##############################

MINIO_PORT=9000

### ADMINER ################################################################################
############################

ADM_PORT=8080
ADM_INSTALL_MSSQL=false

### PHP MY ADMIN ################################################################################
#######################

# Accepted values: mariadb - mysql

PMA_DB_ENGINE=mysql

# Credentials/Port:

PMA_USER=default
PMA_PASSWORD=secret
PMA_ROOT_PASSWORD=secret
PMA_PORT=8080

### MAILDEV ################################################################################
############################

MAILDEV_HTTP_PORT=1080
MAILDEV_SMTP_PORT=25

### VARNISH ################################################################################
############################

VARNISH_CONFIG=/etc/varnish/default.vcl
VARNISH_PORT=8080
VARNISH_BACKEND_PORT=8888
VARNISHD_PARAMS=-p default_ttl=3600 -p default_grace=3600

### Varnish ################################################################################
############################

# Proxy 1

VARNISH_PROXY1_CACHE_SIZE=128m
VARNISH_PROXY1_BACKEND_HOST=workspace
VARNISH_PROXY1_SERVER=SERVER1

# Proxy 2

VARNISH_PROXY2_CACHE_SIZE=128m
VARNISH_PROXY2_BACKEND_HOST=workspace
VARNISH_PROXY2_SERVER=SERVER2

### HAPROXY ################################################################################
############################

HAPROXY_HOST_HTTP_PORT=8085

### JENKINS ################################################################################
############################

JENKINS_HOST_HTTP_PORT=8090
JENKINS_HOST_SLAVE_AGENT_PORT=50000
JENKINS_HOME=./jenkins/jenkins_home

### BLACKFIRE ################################################################################
##########################

# Create an account on blackfire.io. Don't enable blackfire and xDebug at the same time.
# visit https://blackfire.io/docs/24-days/06-installation#install-probe-debian for more info.

INSTALL_BLACKFIRE=false
BLACKFIRE_CLIENT_ID=<client_id>
BLACKFIRE_CLIENT_TOKEN=<client_token>
BLACKFIRE_SERVER_ID=<server_id>
BLACKFIRE_SERVER_TOKEN=<server_token>

### AEROSPIKE ################################################################################
##########################

AEROSPIKE_SERVICE_PORT=3000
AEROSPIKE_FABRIC_PORT=3001
AEROSPIKE_HEARTBEAT_PORT=3002
AEROSPIKE_INFO_PORT=3003

### RETHINKDB ################################################################################
##########################

RETHINKDB_PORT=8090

### MONGODB ################################################################################
############################

MONGODB_PORT=27017

### CADDY ################################################################################
##############################

CADDY_HOST_HTTP_PORT=80
CADDY_HOST_HTTPS_PORT=443
CADDY_HOST_LOG_PATH=./logs/caddy
CADDY_CUSTOM_CADDYFILE=./caddy/Caddyfile

### LARAVEL ECHO SERVER ################################################################################
################

LARAVEL_ECHO_SERVER_PORT=6001

### DOCKER-SYNC ################################################################################
################

# osx: 'native_osx' (default)
# windows: 'unison'
# linux: docker-sync not required

DOCKER_SYNC_STRATEGY=native_osx

##### TO BE CONTINUE .................................

# ......... Missing: neo4j mongo rethinkdb redis aerospike pgadmin...
# .........
# .........

############################
# Miscellaneous
############################

# Replace with your Docker Host IP (will be appended to /etc/hosts)

DOCKER_HOST_IP=10.0.75.1

# The Remote Interpreter entry matching name `laradock`

PHP_IDE_CONFIG=serverName=laradock

# Fix for windows users to make sure the application path works.

COMPOSE_CONVERT_WINDOWS_PATHS=1

Napisany przez: by_ikar 4.12.2017, 19:29:08

Docker na maku czy windowsie działa w wirtualce, więc masz NFS pomiędzy wirtualką a twoim dyskiem, kto kiedyś w vagrancie robił volumeny to wie że jest to bardzo wolne. Dodatkowo zależy co masz namyśli "lokalna maszyna". Jeżeli mówisz o laptopie, to nie, dedyk będzie znacznie lepszy niż niskonapięciowe CPU.

Nie mniej, bardzo często w takiej konfiguracji mysql czy inne bazy po prostu muszą swoje cache rozruszać. Na start nigdy tam nie ma cache, ono zawsze się tworzy pasywnie. Więc wystarczy że poużywasz i powinno się rozruszać. Nie mniej, nie polecam takich kobył używać produkcyjnie, bo to jest drobny żart taki zlepek.

Napisany przez: Pyton_000 4.12.2017, 19:50:35

@by_ikar w Win 10 od wersji Professional Docker odpala się natywnie już i tak też ma odpalony @markonix

Napisany przez: by_ikar 4.12.2017, 21:16:43

Natywnie to działa to tylko na linuxie. Na Windowsie to leci po SMB, z prędkością rzędu 20MB/s i bóg wie jakimi opóźnieniami. Podobnie jest na makach, leci to po jakimś "osxfs" co działa na podobnej zasadzie jak NFS czy SMB, czyli lecą poliki po sieci. Już sam czas dostępu przy języku interpretowany, gdzie każdy jeden plik, z setek istniejących, musi zostać pobrany i zinterpretowany, wystarczy żeby aplikacja muliła jak cholera.

Nie działa to natywnie, wciąż działa to w wirtualnych maszynach, z różnymi systemami plików, których system hosta w ogóle nie rozumie. Natywnie na windowsie może działać kiedy odpalasz kontenery zrobione pod windowsa. Kiedy odpalasz linuxowe kontenery na windowsie, odpala się wirtualka i zaczynają się problemy.

Osobiście staram się jak najmniej rzeczy montować jako wolumen, np zamiast całego katalogu projektu, rezultaty są całkiem zadowalające, aczkolwiek bardzo im daleko do tego jak to działa natywnie na linuksie..

Napisany przez: Pyton_000 4.12.2017, 21:32:56

No tak, trochę przekoloryzowałem z tym natywnie Chodzi o to że nie wymagany już jest virtualBox który zwalniał prze swoje montowania FS

Napisany przez: markonix 5.12.2017, 02:24:13

Tak, przez natywność rozumiem Hyper-V, który jest też formą wirtualizacji tyle, że dostępną od razu w Win 10.

Nie laptop, komputer stacjonarny.

Głównie mnie ciekawi ten objaw opóźnienia, który jest proporcjonalny do przerwy, maksymalnie dochodzi do 10 sekund.
Na razie czym idę dalej tym jest gorzej więc wątpię aby to się samo rozwiązało.
Jak nie ma jakichś ciekawych rozwiązań dla Laradock'a to będę próbował jeszcze na próbę spróbować jakiś inny, czysty obraz z samą podstawą bo jestem ciekaw czy to problem z samym Laradockiem, Dockerem na Win czy czymś innym.

Napisany przez: batman 5.12.2017, 07:27:28

Cytat

Nie sądzę aby to była wina Windowsa zwłaszcza, że ktoś ma podobny problem z jabłku:

To nie jest wina Windowsa, tylko Dockera. Działa on natywnie tylko na Linuksie, pozostałe systemy muszą w jakiś sposób "wirutalizować" środowisko, w którym pracują. Najgorzej jest, gdy korzysta się z volumes. Znalazłem trzy rozwiązania problemu, z których przetestowałem dwa. Oba działają raczej średnio. Aktualnie przymierzam się do skorzystania z docker machine i kontenerów postawionych na virtual boksie.

P.S.
W grudniu wychodzi nowa wersja aplikacji na maca (i prawdopodobnie na windowsa). Może udało im się naprawić problem wydajności.

Napisany przez: markonix 5.12.2017, 11:52:43

A tak odchodząc minimalnie od tematu, jak zaktualizować takiego Laradock'a (i inne analogiczne) gdy on nie jest dodany do composera, tylko jako git submodule.
Czy po prostu ściągnąć zmiany manualnie z repo? Potem co odpalić aby zaktualizować kontenery? Jak tak oglądam pliki to wydaje mi się, że nie powinno nic wylecieć przy takim pullu bo chyba wszystko co istotne trzyma poza katalogiem projektu, ale są też foldery z plikami zmiennymi (chociażby logami) i to wyleci.

Napisany przez: by_ikar 5.12.2017, 12:38:16

Cytat(Pyton_000 @ 4.12.2017, 21:32:56 )

No tak, trochę przekoloryzowałem z tym natywnie

Chodzi o to że nie wymagany już jest virtualBox który zwalniał prze swoje montowania FS

Tak, ale wciąż są dwa różne systemy plików, z dwiema różnymi cechami (uprawnienia, przestrzenie, symlinki, ioevents etc), takie połączenie między dwoma systemami musi zapewne lecieć po jakiejś wewnętrznej sieci (SMB), problemem nie są tyle co duże pliki, co dużo małych plików. Dlatego czasy odczytów są fatalne. I zawsze będą.

Cytat(markonix @ 5.12.2017, 02:24:13 )

Odpal sobie

Kod

docker volume ls

a następnie sprawdź ile masz volumenów, oraz w jaki sposób one są podmontowane. Dla przykładu, w katalogu projektu będziesz miał najczęściej: katalog ".git" który może być spory, katalog ".idea" jeżeli korzystasz z phpstorma i zapewne temu podobne. Wszystkie te katalogi są ci w ogóle niepotrzebne w samym kontenerze, a ciągłe aktualizacje w tych katalogach po prostu nadużywa i tak już wolnego "połączenia" pomiędzy wirtualką z dockerem a samym windowsem/makiem. A z tego co widzę po tych plikach, to tam nawet baza danych jest zmontowana lokalnie, co daje kolejny ogromny narzut. Użyj jakiegoś innego rozwiązania, gdzie będziesz miał rzeczy które są ci potrzebne i porównaj czy wciąż będzie to chodzić tak gównianie.

Cytat(batman @ 5.12.2017, 07:27:28 )

To jest wina windowsa, jak i osx'a. Gdyby te systemy w jakiś łatwiejszy sposób umożliwiały czy to wirtualizowanie czy konteneryzowanie innych systemów, o obsłudze innych niż "słuszne" NTFS systemów plików nie wspominając (oczywiście w przypadku windowsa), to by się to wszystko lepiej integrowało. A tak z racji sporych różnic pomiędzy systemami, powstała proteza, żeby użytkownicy windowsa czy osx'a nie byli gorsi i mieli swojego "natywnego" dockera, bo wiadomo, teraz kontenery są hiper popularne. Na codzień pracuje na osx'ie, wcześniej pracowałem głównie na ubuntu i przejście było najbardziej bolesne, kiedy się okazało jakim kastratem jest osx pod względem narzędzi developerskich na których dotychczas pracowałem. Nie zrozumcie mnie źle, windows, mak czy linuks to są dobre systemy i każde z nich ma swoje zalety i wady. Jako że dla mnie istotny jest development, to z automatu na samym końcu ląduje windows. Maka mocno ratuje społeczność i uniksowa kompatybilność. Gdyby stworzyli coś zupełnie swojego, zapewne byłoby tak samo jak z windowsem..

Aby podsumować ten wywód, na windowsie czy maku istotne jest to co montujecie. Jak twój projekt jest w katalogu `~/projects/my-project` a w katalogu projektu istotne są tylko katalogi `~/projects/my-project/vendor` i `~/projects/my-project/src`; to montujcie tylko te dwa katalogi, zamiast całego katalogu z projektem. Nie montujcie plików z bazy danych - użyjcie named volumes (nie przepadną wam dane, ale nie będziecie tego montować lokalnie). Jak pracujecie na wersjach developerskich aplikacji, mimo wszystko włączajcie cache i inne. Jeżeli w projekcie macie pliki które mają różną wielkość znaków, pilnujcie żeby odwołania do tych plików były prawidłowe, z racji tego że windows czy mak ignorują wielkość znaków (na maku można to wyłączyć) to będzie wam szukało plików w kilku wariantach, co będzie minimalnie wolniejsze.

Jeżeli mimo tego aplikacja działa wolno, a dockera używacie bo to jest "fajne", to zastanówcie się nad po prostu instalacją projektu lokalnie. U mnie używam kontenerów w developmencie, stagingu oraz produkcji. Nie mniej, debugowanie kodu lokalnie, w kontenerach do których nie ma się łatwego dostępu (w przypadku maków ułomna jest też sieć, nie istnieje interfejs docker0 dzięki któremu można dostać się do kontenera po jego IP, trzeba wszystko bindować lokalnie i dostawać się po localhost..), staram się aby tylko bazy danych działały w kontenerach, a samą aplikacje odpalam lokalnie i łącze się do tych baz danych. Nie ma innego wyjścia, trzeba sobie jakoś radzić..

Napisany przez: markonix 6.12.2017, 14:20:27

Tylko cały czas ciekawi mnie objaw tego opóźnienia, aniżeli sama wydajność Docker'a bo ta przyznaje, póki co jest 1/3 wolniej niż serwer ale to ciągle mniej niż 1 sekunda i bym to tymczasowo przebolał.
Natomiast ciekawi mnie ten objaw przerwy.
Zaraz po włączeniu Dockera i po długiej przerwie czas uruchomienia: 2x4 sekundy.
Dłuższa przerwa: 2x3 sekundy.
Krótka przerwa: Mniej niż 1 sekunda (normalnie).
Wyraźnie coś ładuje, jakiś cache traci się i z tego co pamiętam na Vagrant też tak miałem że pierwsze odpalenie było dłuższe ale potem już było cały czas ok.

Napisany przez: nospor 6.12.2017, 14:29:53

A moze poprostu twoja aplikacja na docker ma inna konfiguracje niz na serwer a co za tym idzie inaczej sie zachowuje?

Napisany przez: markonix 6.12.2017, 14:46:08

Hmm, jaką konfigurację masz na myśli? Pliki env praktycznie są zbieżne, sama konfiguracja serwera jak najbardziej może nie być ale nie wiem od czego zacząć przy "wyrównywaniu" środowisk.
Jak bym miał coś szukać to z jakimś cache, tylko pytanie czemu lokalnie tego cache nie trzyma albo trzyma ale tylko minutę + są jakby 2 zestawy bo aplikacja ładuje się w 1 sekundę, 6 sekund (teraz np. pisząc tego posta) i te najdłuższe 8 sekund.

Napisany przez: nospor 6.12.2017, 15:06:16

zazwyczaj, konfiguracja lokalna aplikacji jest inna niz tej na serwerze.
Przykladowo w symfony lokalnie nie musisz recznie czyscic cache, na serwerze juz musisz. To tylko jeden z przykladow.

A moze to faktycznie ci muli z jakiegos powodu jakis kontener. Z jakiego to wiadomo - windows
Juz to mowiono tu wczesniej, ale moze zamiast bawic sie w kobyle laradoc zrob wlasnego docker-compose

Napisany przez: markonix 6.12.2017, 15:51:10

Ktoś poleci jakiś sprawdzony obraz? Nginx, php 7.1 (+ rozszerzenia), mariadb?

Napisany przez: by_ikar 7.12.2017, 08:17:03

Użyj oficjalnych obrazów i posklejaj to sobie w docker-compose. Jest to trochę dodatkowej wiedzy, ale dzięki temu będziesz wiedział jak działa całe twoje środowisko, a nie musiał się zastanawiać, dlaczego coś gdzieś ci muli. Polecam korzystać z obrazów gdzie bazą jest alpine (często w tagach jest np nginx:alpine), głównie ze względu na ich minimalizm oraz wydajność.

Napisany przez: Pilsener 7.12.2017, 09:52:31

Nawet jak lokalnie uda się w 100% zasymulować środowisko to i tak jest jeszcze problem danych, różnych API etc. Dlatego ja preferuję rozwiązanie, które polega na równoległym postawieniu aplikacji w trybach dev, staging oraz production. Kod napisany lokalnie jest sprawdzany na dev, potem staging (produkcyjne dane) i w końcu trafia na produkcję. Przy debugowaniu kolejność rzecz jasna odwrotna.
Wkurza mnie, kiedy bug na 15 minut zajmuje 15 godzin bo muszę ogarnąć środowisko, pobrać dane, wstawić zaślepki dla jednych API, zasymulować działanie innych etc. A prawdziwa tragedia, gdy masz architekturę rozproszoną i jeden serwis jest zależny od drugiego przez jakiegoś rabbita etc.
Dlatego nie ma sensu się spinać by lokalnie mieć identycznie jak na serwerze - jak Ci docker zamula to go po prostu nie używaj.

Napisany przez: memory 7.12.2017, 13:33:24

http://dockerfile.readthedocs.io/en/latest/content/DockerImages/index.html

Napisany przez: batman 10.12.2017, 02:20:11

Cytat(by_ikar @ 5.12.2017, 12:38:16 )

Równie dobrze możesz napisać, że to wina Windowsa, że nie można na nim odpalić aplikacji z iPhone'a. Docker po prostu sobie nie radzi na Windowsie i na MacOS. Ale nie o tym chciałem pisać. Szukając rozwiązania problemu natknąłem się na takie coś: https://docs.docker.com/docker-for-mac/osxfs-caching/ (a już chciałem odpalać docker-machine). Nadal nie jest to idealne rozwiązanie i czasami projekt potrafi zamulić, ale poprawa jest wyraźnie zauważalna.

Napisany przez: by_ikar 13.12.2017, 10:15:44

Cytat(batman @ 10.12.2017, 02:20:11 )

Nie do końca chodziło mi o sam fakt działania aplikacji z systemu A na systemie B, bardziej mi chodziło i braki jakie inne systemy mają w stosunku do linuksa. Największym brakiem w tym przypadku jest przyspawanie systemu do pewnych rozwiązań i zamknięcie się na wszystko to co dzieje się dookoła. Windows jest tutaj pięknym przykładem takiego lock-in, nie da się tam użyć jakiegoś zaawansowanego systemu plików pokroju btrfs, nie da się użyć niczego poza NTFS/FAT*, chyba że jest to partycja nie systemowa to wtedy można skorzystać z ReFS o ile masz licencje na "lepszego" windowsa.

Nie mniej, znalezisko godne uwagi, nie widziałem tego, ale na szybko przetestowałem przed chwilą - zaskakujące rezultaty. Wcześniej jak odpalałem testy, to szły na maku jak krew z nosa (kiło kilku minut), gdzie na AWS'ie na instancji t2.micro (1CPU+1GB ram - vps za ~35zł miesięcznie) takie testy przechodziły poniżej 30 sekund. Teraz po dodaniu cached (pliki) i delegated (baza danych) testy przechodzą w podobnym czasie co na maszynie z linuxem. Zajebiscie.

Napisany przez: markonix 9.01.2018, 16:31:26

Na razie problemu z Dockerem nie rozwiązałem (stawiałem Laradock od nowa i była między czasie aktualizacja Docker'a), jedynie znam już pośrednio przyczynę tj. ram/obciążenie.
Tj. lagi nie są regularne w sensie interwałów czasowych tylko pojawiają się gdy wykonuje jakieś cięższe operacje (np. dużo kart w przeglądarce, odpalę jakąś grę itp). Generalnie jak mam czysty, włączony dopiero komputer, storm + przeglądarka + docker to opóźnienie się nie pojawia, potem jak już zacznę śmiecić np. włączę YT to już pojawi opóźnienie.

Ale ja nie do końca o tym, błysnęło mi przed oczyma takie coś:
https://laragon.org/
Nie powiem, opinie pochlebne w sieci.

Szkoda, że nikt tematu nie podjął, więc ja dzisiam wracam z garstką doświadczeń.

Wyszła dzisiaj jakaś aktualizacja Dockera, puściłem aktualizacje, wykrzaczyła się, patrzę.. A tu cały Docker wyleciał (w sensie program).. Zostały tylko śmieci na C które ciężko usunąć.
Irytacja zmotytowała mnie do spróbowania owego Laragona i powiem szczerze - jest dobry. Wydawałoby by się że taka nakładka w postaci tego całego intrfejsu jakoś ograniczy w funkcjonalności, ale póki co odpaliłem mój sporawy projekt bez większych komplikacji (zajęło mi to gdzieś z godzinkę ale to głównie dlatego że tu sobie wgrałem maria db zamiast mysql, nginx zamiast apache, phpmyadmin na dokładkę). Sam projekt działa po prostu SZYBCIEJ o przynajmniej połowe. Średnia na wczytanie wg Debugbar to pół sekundy, jak dobrze pamiętam przy Docker było to zwykle około 1 sekundy. Odczuwam też subiektywnie że strony ładują się szybciej, pewnie też przez przyspieszenie ładowania assetsów.

Owych lagów nie ma albo są bardzo rzadko i znacznie krótsze (3 sekundy), może to już faktycznie jakieś operacje Laravela.

Wad i ograniczeń na razie żadnych nie odczułem, jedyna moja obawa to Windows-only czyli znacznie mniejsze community niż od rozwiązań multiplatformowych.