Closed xdega closed 6 years ago
IMO doing docker well means having a tailored app setup. Doing any kind of general-purpose containers is going to get messy for people and lead to them being very confused. Docker isn't the simplest thing to pick up much less start modifying how it runs.
This is something that shouldn't be included since from what I am seeing, developers are already confused enough about all the various tooling and methods of doing things Laravel offers. Either other things need to be dropped completely to make this the primary way or it shouldn't exist internally. It's just too many facets to do the same thing.
Further, there is no need to make a new issue. Just comment on the original you referenced. It's literally asking the same thing you are.
The reason I opened a new issue, was because the other one was quite old. Didn't want to "necro" it.
I agree it is overwhelming. I can say, though, that two-weeks of blood, sweat, and tears, and it really makes a lot more sense. Furthermore, the adoption rate of Docker is incredibly high right now. It is something that I am confident we are all going to need to be familiar with at some point in the near future. In a similar way to how Object Oriented Programming changed the way we wrote code, containers are changing how we build/develop applications.
Also. I am suggesting that Laravel include a "base" layer that can run Laravel at the core, that simply creates what would amount to a homestead-like environment.
User's can then add their own "build" layer on top of the official implementation.
Part of the beauty of Docker, is the layered architecture.
In terms of how to implement this. I think this is a very clean example of how such an integration could be accomplished: https://github.com/kyleferguson/laravel-with-docker-example
It adds the bare minimum of what is required and is well documented.
It is my understanding that the ./deploy
directory, and ./docker-compose.yml
are the only non-core files that are added here.
This shouldn't be in laravel by default. :2 cents:
I think for most Laravel users, taking advantage of docker is akin to using a nuclear bomb to take care of a few ants in your yard. Sure, it can get the job done but it's going to cause more problems than it solves.
Docker is NOT intended for everything we do. It's aimed at primarily being used in applications that have various fluctuating needs as far as resources at any given minute of the day. While yes, it may be really nice sometimes for smaller things, it isn't solving any actual problem. Instead, you need to understand what is going on inside of docker and avoid some major pitfalls. Or else you'll end up making more work for yourself throughout the development and lifetime maintaining an application.
We get it, Docker is the hot-newness that everyone wants to try and learn and a few can't be quiet about. But at the end of it all, It's just a tool that is not appropriate to the average Laravel developer. Let's not over-complicate things.
I find the idea that everyone ought to set up local development environments, in a vast array of inconsistent configurations to be far more complicated in the long term. Especially when it comes to pairing your local environment, with that of your live/production environment.
Docker can be as complicated as you make it. At the bare minimum, however, it provides a way to create consistent and up-to-date environments. And for most users, just knowing that they can type docker-compose up -d
in their command line, and run their project in a disposable environment, without having to install or set up anything besides Docker. Then being able to type docker-compose down
when done with working on the project. This is really no different than the concept of php artisan serve
, albeit a monumentally more powerful system for doing such.
One has to ask WHY this is the "new hotness"? Why the adoption rate of Docker is what it is? The answer is that it does indeed address a plethora of development issues. All for the sake of adding less than half a dozen, plain text, configuration files to the core webroot of a Laravel install.
If one is apt enough to know how to docker compose up
they're apt enough to be able to set Docker up for their own app. Anyone who'd "benefit" from it being included in your install are just gonna be confused and flood the issue tracker with "my docker broke"
If your project/team needs Docker, cool you know how to add it. But the simple fact is, it's overkill. But, all I can do is provide my understanding and context. Whether or not others agree is its own thing. Clearly you don't and you feel Docker is something every developer on the planet should be using. Even if they don't know how nginx or apache talk to the PHP process in the first place.
@Garbee How many people know the ins and outs of how Laravel works "behind the scenes"
I think my suggestion is being considered far more "intrusive" than it actually is. We are simply talking about adding a YAML file, and a couple of plain text config files. In the process, future-proofing Laravel for the "Docker revolution", and facilitating a modern web-development workflow. That is all.
I don't see this as being any more significant than Laravel implementing technologies like Node, Vue, etc. In fact, it is what I have come to love about Laravel over the years. The dedication to being open to modern web practice.
Perhaps we are a little too "early" for this. But flatly rejecting it on the basis of complexity does not sound valid to me. It isn't complex unless you are trying to understand literally everything that is happening behind the scenes. I am willing to bet that many Laravel developers are not understanding everything that is going on behind the scenes in their application.
Laravel is already good for "the Docker revolution" I use Laravel with Docker in production without needing any of that stuff.
It isn't based on complexity but the fact that people using Laravel already barely understand a simple web server setup. Now you want to add Docker in by default on top? It's simply too much.
Docker is not something to just use willy-nilly. It should be a calculated and direct decision by a developer/team/organization.
@xdega I can't speak for @taylorotwell , but perhaps doing a PR to the Laravel Docs to list Docker below Homestead/Valet https://laravel.com/docs/5.4/valet might be an alternative, particularly if you're amenable to helping maintain that section of the docs going forward.
I'm just thinking that since neither Homestead nor Valet are directly integrated into Laravel as they're optional devops choices, but are still in the docs, your willingness to help empower people to use Docker might sit well in that same space.
@drbyte Your suggestion is fair. As for tracking the necessary files for said implementation, I suppose I could create a public git for that. I would be more than happy to maintain a section of the documentation.
@Garbee Let me be clear. I am not suggesting Docker be "imposed" in any way. Simply suggested as an option for developers, with varying needs. Adding support wouldn't mean adding a dependency to use, any more than other optional services that Laravel supports. (ques, mail, cache, etc)
Just to update.
The previous Laravel integration I shared appears to be unresponsive to pull requests and has an issue with using links, vs networks in the Docker compose script.
As such, I have created this repo https://github.com/xdega/laravel-with-docker. I welcome pull requests and collaboration on this.
A Laravel 5.4 install, and the minimum necessary configuration files to enable Docker support. I plan to create a "minimal" branch, which has only the Docker support files, for those we wish to have the flexibility of installing their own Laravel and adding Docker support files separately.
Hope to get started on some content for the Laravel documentation this coming weekend.
Hi. This my first issue submission, but something I feel is quite important/legitimate. Related to issue #128
Like many of us who work professionally in Web Development, Docker has been exploding on the scene. Even more so, since the last request on this last year.
The notion of building disposable development environments is a game-changer. It allows for consistent workflows, with proper dev-production parity. Something that my own previous workflow, via Laravel Valet, did not have.
I am about to begin a new Laravel based project, and will be "Dockerizing" my application via a
docker-compose.yml
file that will live in the webroot. And will allow Docker users to rundocker-compose up
to build their local development environment on command.Is there interest in implementing this support to the Laravel core? If so, I will happily share the "leg-work" that I am inevitably going to be completing.
PS: I am aware of Laradock, but that is a bloated implementation, that does far more than necessary for a simple, and minimal, container-based development environment. It also runs the risk of lacking maintenance, due to being an independent project, thus possibly losing parity with Laravel core in the future.