Docker

+1 I would love to see a Docker tutorial because it is a real pain-in-the-ass to setup a dev environment!!!

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.

Whats wrong with Homestead using Vagrant, easy enough to setup on both Windows and Mac and effective enough to run everything from. Just my opinion!

@Istables Thing is you can take those container for production as well having less issues when you deploy into production. That is why i really want to get into it.

@Colossus you can do that already with Homestead. Then just copy/paste your env file.

You are not understanding my point, you will have the same mysql version for example on both dev and production using the same container that allowd for automation and all of the CI goodness.

@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.

Yes, a Docker dev environment + something like deployment of Docker containers to AWS Elesticbeanstalk would be super helpful.

Did you signed up at Docker and read the docu? The Tutorial is super helpful and with a bit of understanding you can setup your env by yourself with docker. particularly because docker comes with a super dooper UI (Kitematic).

Just read a bit and try it.

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".

Maybe I'm just getting old and jaded, but I can't help myself expecting the phrase 'web scale' to pop up ;-)

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.

1. 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?

2. 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.

3. 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.

4. 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.

5. 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.

So following this I have created my own package to dockerize your laravel application. It can be found right here : https://github.com/SteveAzz/laravel-docker

Jeffrey should really recap Docker as a dev env cause it's not furure safe to continue with Vagrant based environments.

I've switched to docker but I keep homestead as backup just in case I do not know how to do something with docker, but that didn't happen yet.

A docker series on laracasts would be great!

+1 - I would definitely like to see this as well.

FYI, Chris Fidao just released a good beginners tutorial called Shipping Docker here: https://shippingdocker.com/

Still, it couldn't hurt to have Jeff add his master touch to the subject.

I can understand @jefferyway not producing a series on docker, @taylorotwell endorses homestead for starters. I have never used Homestead but Docker containers are also very small and I don't think the homestead platform has a solution to compete with the convenience of Docker Swarm(?)

I started using docker for managing my environment and it is fantastic. No more worries about provisioning redis, laravel echo server, workers queue, blahblah blah, just make a suitable image for each process, use docker-compose to orchestrate them and your done. I may write on this topic someday.

If you need advices you can ask me.

If anybody wants an image to start I created https://hub.docker.com/r/primordial/alpine-nginx-php7/ for my stuff and same as @pmail; happy to help.

+1

I am using Laradock: Like Laravel Homestead but for Docker instead of Vagrant. for personal projects and it works great on Windows!

I'm creating Shipping Docker which will go in-depth on teaching Docker for development and production.

There's a free mini-course on getting up and running for development (along with explanation of what's going on)!

Definitely sign on up there to get some extra videos and notified when it's out! (And of course coupons, blah blah blah)

Hey so anyone still wanting to use docker with Laravel, Here is one running PHP7.0, MySQL 5.7 and Nginx I have set up and use all the time.

https://github.com/michaelmano/Dockers ( you will not require these files. This is just the repo You will only require Docker installed )

Getting Started

You do not require any files except Docker installed.

If you are starting a new project from scratch this container will create a Laravel project in the path you provide it and update the .env to the dockers database details. If you have an existing project and you provide it the path it will not install Laravel but instead use your project.

If you destory your docker when you are finished the files will be left on your computer so you will not lose anything (except the database however if you are using migrations and seeders you should be fine - if you require the database I suggest you do a mysql dump before hand with the dockers exec command).

Commands

Creating a Container The command below will spin up a new docker container named my-project running on port 80, You can change this if you have multiple projects by altering the -p 80:80 to -p 8888:80 (8888 to any port you prefer).

docker run --name my-project -itd -v /path/of/project:/var/www -p 80:80 -P michaelmano/laravel

Running Commands on the Container

docker exec -it my-project /bin/bash -c "php artisan migrate"

or open a console in the container

docker exec -it my-project /bin/bash

Destroying a Container This will leave the project folder it was using so all files will be safe.

docker rm my-project -f

Checking the Container Status

docker ps -a

This will show the containers you have running and on which port however you can use dockers Kitematic which is a visual interface for this also.

MySQL Details

• dbname: docker
• user: docker
• pass: docker

TODO

• Automatic install of laravel - (Completed)

Just an update to the above post. I have now added sqlite to the docker so testing is possible in memory with sqlite.

just update your phpunit.xml to the following around line 27. I will also do this automatically on install of a new project.

        <env name="DB_CONNECTION" value="sqlite"/>
        <env name="DB_DATABASE" value=":memory:"/>

Would love to learn Docker + Kubernetes the Jeffrey Way.

Docker originally used LinuX Containers (LXC), but later switched to runC (formerly known as libcontainer), which runs in the same operating system as its host. This allows it to share a lot of the host operating system resources. Also, it uses a layered filesystem (AuFS) and manages networking.

AuFS is a layered file system, so you can have a read only part and a write part which are merged together. One could have the common parts of the operating system as read only (and shared amongst all of your containers) and then give each container its own mount for writing.

So, let's say you have a 1 GB container image; if you wanted to use a full VM, you would need to have 1 GB times x number of VMs you want. With Docker and AuFS you can share the bulk of the 1 GB between all the containers and if you have 1000 containers you still might only have a little over 1 GB of space for the containers OS (assuming they are all running the same OS image).

A full virtualized system gets its own set of resources allocated to it, and does minimal sharing. You get more isolation, but it is much heavier (requires more resources). With Docker you get less isolation, but the containers are lightweight (require fewer resources). So you could easily run thousands of containers on a host, and it won't even blink. Try doing that with Xen, and unless you have a really big host, I don't think it is possible.

A full virtualized system usually takes minutes to start, whereas Docker/LXC/runC containers take seconds, and often even less than a second.

There are pros and cons for each type of virtualized system. If you want full isolation with guaranteed resources, a full VM is the way to go. If you just want to isolate processes from each other and want to run a ton of them on a reasonably sized host, then Docker/LXC/runC seems to be the way to go.

Visit here! https://goo.gl/68Xj1t

+1 on wanting a docker series.

Many of the Continuous Integration services uses docker to run environment and test the project.