search

markomitranic / docker-php-example

51 stars 7 forks source link

Question why upping/building twice (in beforeCreate and afterCreate steps) #2

Open thijskaspers opened 2 years ago

thijskaspers commented 2 years ago

Hi there, found this repo and I'm new to Mutagen to speed up Docker for Mac. I love it so far! Thanks for your awesome article about docker performance!

I was wondering why you up and build the container in both beforeCreate and afterCreate step? Isn't it enough to do it once in beforeCreate?

https://github.com/markomitranic/docker-php-example/blob/315ed2d173525fad7cffa5192b6bd169fd4ba4af/mutagen.yml#L17-L24

markomitranic commented 2 years ago

Hey @thijskaspers yeah, you are completely correct in that. The build however never happens, because it was already build, so its just loaded from cache, and thus I've never felt the need to change it.

Also, this was abandoned a long time ago, so there may be better practices for mutagen nowadays. For example, I advocate for full development inside a Linux VM (or even better a VPS) without any shared folders nowadays. :)

thijskaspers commented 2 years ago

Okay thanks! We still have some homework to do then :)

We see big improvements in speed with Mutagen over the standard Docker for Mac file sharing (gRPC fuse). It's also faster than the NFS mounts we previously used. It seems Docker for Mac will soon get "Virtiofs" support for faster filesharing out of the box, but the tests show that Mutagen will probably still be faster. Only downside with Mutagen is it needs more configuration and a different entrypoint process, but we think it's worth it.

Full development in a Linux VM sounds interesting. We've looked at a VPS but found it too inconvenient for our developers that work on multiple smaller projects at once. We are trying to find an easy "docker-compose up" solution that'll quickly up the website on localhost and can be worked on with PHPStorm, at good performance.

Will a Linux VM be able to provide this through a tunnel or something like that? Or do you mean you'll run/see everything from inside the VM, basically working on Linux instead of MacOS?

markomitranic commented 2 years ago

@thijskaspers Oh yeah, whatever they do with their filesystem, mutagen will still be faster as it is literally just fancy-pants rsync wrapper. So, from the perspective of the container, the files are locally on disk and the file operations have no overhead.

I agree with you, we ended up using mutagen for quite a while, as any drawbacks of it were quickly offset by the sheer speed gains. We were working on a humongous Symfony project and our local pageloads were ~1-2min each on D4M. With mutagen they dropped down to a much more reasonable 10sec. However due to the enormous amount of files our projects had, we often had mutagen "get stuck" or drop a volume. Our config was riddled with ignore patterns. A nice side effect of that was that it prompted us to rearrange stuff on the project so that it better fits into the Docker paradigm.

At my current company we use VPS or a Vbox VM for running docker. Nobody keeps any files locally and simply keeps everything inside the "workbox". In the morning, I connect to it, and there I have my ~80 microservice projects. I run what I need, work with what I work, and then commit/push directly from there. My local machine does not have any of the K8s, Elixir, PHP, git, Node, Python binaries, nor does it know what Docker is.

Each project has its own startup shell script located in the same place ./scripts/run-dev.sh. This allows us to have the same interface for all projects, regardless of if they use docker-compose or docker run internally. Here is an example we'd use for docker run:

#!/bin/sh

set -e # Any command which returns non-zero exit code will cause this shell script to exit immediately
set -x # Activate debugging to show execution details: all commands will be printed before execution

# Ensure the .env file exists
if [ ! -f .env ]; then
    cp.env.example .env
fi

docker build -f dev.Dockerfile -t panacea:local .
docker network create -d bridge vitalbeats || true

docker run \
    -v $(pwd):/app \
    --name vb_panacea \
    --env-file .env \
    --network vitalbeats \
    -p 4000:4000/tcp \
    -it --rm panacea:local

For docker compose it would pretty much just have docker-compose up --build and perhaps a block to capture exit signals so we have graceful shutdowns.

Now - the tricky part. I was able to do so because I dropped PHPStorm a long time ago in favor of VSCode. It seemed very hard at first, but it took me just a little bit to get all set up, and I've never looked back since. I understand that this is a deal breaker for most people who are loyal to their IDE, but it was much less of a difference than I've been led to beleive.

My debugger works, autocompletion, wordpress and symfony bindings, linters and quality checks. Pretty much every language I touch has them, and so does PHP. From this perspective I am not really even sure why I was so hot about PHPStorm back in the day. In fact, with a simple settings json file, I define extensions and their settings for each project, so my developers literally don't even know how it works, they just spawn the container and open the editor and everything is already there. In PHP, Python, JS, Elixir, Terraform, Groovy... I explain this in more detail here: https://medium.com/homullus/remote-development-or-how-i-learned-to-stop-worrying-and-love-the-mainframe-90165147a57d#fde9

However I can fully understand that not everyone is ready to jump the gun (It took me a hard push to switch) so as proof - JetBrains is actually working on a new editor "Fleet" which is set to be a carbon copy of what VSCode does, especially when it comes to remote development :D

Anyway, it is worth that you check out this repo of mine that the team I worked at uses nowadays: https://github.com/markomitranic/docker-mac-vagrant