Hi! I decided to try out the Docker installation of Shopware too experiment with it without tinkering with my local development environment too much, and I already run most things in Docker containers (I kinda love them more than... Puppies? 🐶).
Problem
./psh.phar docker:start gave me an error when it tried to bind port 9200 for ElasticSearch, the app_es service in the docker-compose.yml it seems.
I realised that I still had my own ElasticSearch container running so I first stopped the running ElasticSearch container and also ran ./psh.phar docker:destroy to make sure that the error didn't cause any hiccups when I'd ran ./psh.phar docker:start again, but...
I expected the destroy action to destroy all the containers that were created by the services in the docker-compose.yml, which is also used in the start action. The stop action gave me the impression that it'd only run a docker-compose stop instead of docker-compose down, so I decided to use the destroy action.
After all this I looked at my containers and images, and they were all gone.
Solution?
I'm mostly blaming myself for this because I should've looked more careful at the commands I was using and not make the assumptions I made.
At the same time I feel like a Docker installation like this shouldn't have commands that have an effect outside the scope that was instantiated when the installation was set up (./psh.phar docker:start).
A warning might've prevented this, but at the same time, when using "stop" as the term in relation to Docker (./psh.phar docker:stop), it should not use docker-compose down which actually destroys all the resources that were created by the Docker Compose YAML.
In case of ./psh.phar docker:destroy, in my opinion it shouldn't affect resources (Docker containers, images, volumes, etc in this case) outside the scope that I described a few sentences previously.
I'd love to hear from you guys and your opinions you on this matter! 🚀
Hi! I decided to try out the Docker installation of Shopware too experiment with it without tinkering with my local development environment too much, and I already run most things in Docker containers (I kinda love them more than... Puppies? 🐶).
Problem
./psh.phar docker:startgave me an error when it tried to bind port 9200 for ElasticSearch, theapp_esservice in thedocker-compose.ymlit seems.I realised that I still had my own ElasticSearch container running so I first stopped the running ElasticSearch container and also ran
./psh.phar docker:destroyto make sure that the error didn't cause any hiccups when I'd ran./psh.phar docker:startagain, but...I expected the destroy action to destroy all the containers that were created by the services in the
docker-compose.yml, which is also used in the start action. The stop action gave me the impression that it'd only run adocker-compose stopinstead ofdocker-compose down, so I decided to use the destroy action.After all this I looked at my containers and images, and they were all gone.
Solution?
I'm mostly blaming myself for this because I should've looked more careful at the commands I was using and not make the assumptions I made.
At the same time I feel like a Docker installation like this shouldn't have commands that have an effect outside the scope that was instantiated when the installation was set up (
./psh.phar docker:start).A warning might've prevented this, but at the same time, when using "stop" as the term in relation to Docker (
./psh.phar docker:stop), it should not usedocker-compose downwhich actually destroys all the resources that were created by the Docker Compose YAML.In case of
./psh.phar docker:destroy, in my opinion it shouldn't affect resources (Docker containers, images, volumes, etc in this case) outside the scope that I described a few sentences previously.I'd love to hear from you guys and your opinions you on this matter! 🚀