Published 2 years ago by SteveAzz
Hello, i just wanted to know if there is any toughs about talking about docker and setting it up with laravel, or is it better to stick with vagrant for laravel development since there is homestead
I'm 99% sure that Jeffrey won't do a tutorial on this subject because it is so specific. There is not that much users that will use it here on Laracasts, since most users will be beginners or with some experience.
Anyway, does this help you out: http://www.dylanlindgren.com/docker-for-the-laravel-framework/
Personally I don't see what docker would add to laravel app development 99.9% of the time. Especially if you're developing on MacOS or Windows as you need to boot a VM anyway so may as well use vagrant/homestead. OpenVZ probably has more of a place imho.
Generally I only use docker for isolating single binary processes across various Linux distributions (for instance there's maybe a package ready-built for Ubuntu that you want to run on a CentOS server - so you can wrap it up in a container) and I can see the need if you require 100's of the same processes at scale - but in that case you probably have way more things to focus on than laravel itself.
@Colossus and you can do that with vagrant dev - but without the hassles containers give you. If your production is, say, centos 6.5 with the vendor mysql, then just make a vagrant centos 6.5 box. In my experience of using containers, they can be useful but are full of traps that you need to watch out for (like dockerfiles that just install packages/libraries without specifying the version), monitoring them can be tricky without adding a load of other containers/stack stuff - whereas your current 'real' production environment probably has all that sorted in a well understood way.
Docker is getting big! For sure now it's a trend. I guess it's not the place to discuss why, but for me it's like a development/deployment/production standardization tool. Many cloud providers (AWS, DigitalOcean, Azure, Google Cloud, etc.) now natively support Docker. You create your project configuration once and then use it anywhere and get absolutely the same environment, isn't it cool? It solves hundreds of problems!
@bobbybouwmann Yes, that's the ONLY one useful article I could find! But it's a bit old now and when I tried to implement everything I've read - I ran into a dozens of issues and now I have more questions then answers... :(
@JeffreyWay has a big talent to educate people, so I'm sure, my brain will be clear after watching his Docker series! By the way laracasts is one of the main reasons I chose Laravel for my current project. Thank you @JeffreyWay :)
@kayyyy It's not just about setting up a dev environment that works. It's about setting up something that is deployable to other environments in a way that works well with autoscaling.
Obviously it is possible to learn without Laracasts by reading documentation and trying, but that's true for everything else here on Laracasts as well ;-) And there seems to be an information gap between "how to set up a docker instance locally" and "here are the issues we at Spotify had setting up our production environment with docker".
I'm not making the argument that Docker is a good subject for Laracasts, Dr. Way should be focusing on the 70-80% crowd, but Docker is exciting for us (at work) for several reasons.
Our NetAdmins are not dev friendly and have locked us into Hyper-V for VMs, which renders Homestead/Vagrant/VirtualBox/PrettyMuchEverythingVMRelated useless. However, I can run a Linux HyperV VM that has Docker on it, which means I can have several containers in a single VM?
There are tons of ready to roll "recipies" and Bitnami is getting on board, which is something we already use, so we don't have to completely revamp our server architectures.
Dev = Test = Production in term of environment configs becomes a vastly reduced concern since the Docker images are the same. This is perhaps the one reason that should apply to "public" community not just those of us using Laravel in the Enterprise.
dotEnv has some bleed over issues with running multiple virtual hosts on the same system, so attempted to host multiple sites in one VM can lead to weirdness. It doesn't really matter if you are using dotEnv, if you are stashing configs in the environment variable scope name collisions, mutability, superglobal exposure, and several other things are issues that need to be considered. Containers go along way towards eliminating these types of issues as each site is in its own space.
Over provisioning your hardware with tons of VMs is super easy to do. I am not 100% versed in Docker but it seems you would be able to get more containers than VMs on the same hardware and not push your hardware provisioning so hard.
Don't dismiss these types of tools in favor of what ships with Laravel as the "out-of-the-box" tools are not always viable depending on the context of the project.