Answer the question
In order to leave comments, you need to log in
How to properly organize development on Laravel + Docker?
Greetings! I'm working on my project, for a long time my development cycle went according to the scheme "wrote / updated the code -> launched and tested in vagrant/homestead -> uploaded via ftp in production to my vds". I know it's a terrible plan.
I have read articles about the benefits of git, CI/CD, Docker, automated testing and deployment, and now I want to use these technologies in my project. With theory, everything is approximately clear, but how to apply all this in practice is still vague. I went through several getting-started Docker guides, learned the basics, how to run nginx under Docker with a static website.
Specific question: what should the "correct" development flow on Laravel + Docker look like? It's not clear to me how to use Docker with Laravel, because the application uses a bunch of different components: nginx, php-fpm, git, composer, psql, redis, npm/yarn. What should be the containers for all this, how should they interact and what should be the final result in production? In vagrant, all this was installed inside one vm, that is, it resembled a vds server, but in Docker, as far as I understand, there is a completely different philosophy.
I read about laradock, but for some reason they say in an article on Habré that this is not very good - there are problems with automation and launching on production, I don’t know if this is true.
I would be grateful for your advice and help!
Answer the question
In order to leave comments, you need to log in
You have a small project and it is difficult to apply a full-fledged CI / CD to it - there is little point in containerization if there is no need to scale, balance and ensure the survivability of the service. Development should be done using a bunch of containers with nginx, php-fpm, redis, postgresql, etc. - when developing locally, everything is placed in docker-compose.
In production - in your case, you can get by with just docker or using the same docker-compose. In large projects, there will be, for example, kubernetes, nomad or docker swarm for sale. All containers are deployed and configured once. Your CI/CD should build a container based on alpine and php-fpm (for PHP) or nodejs (for nodejs, respectively) with your project, preferably in a couple of stages to minimize the size of the final image, because you do not need a composer, git, yarn, npm and other intermediate things in the production. And this minimum container is already leaving for production.
Also, at random, I studied a similar bundle (though with Yii2). The result is this configuration:
So far, all development flies to the git master branch. Uploading from "development" to a server occurs using Deployer. In principle, after setting everything works like clockwork.
The code is separate from the container. Deploying code in a container is already another level (and it’s not a standard practice at all), I personally haven’t had a need yet.
The task was to make it as easy as possible to move to another host, with editing one config (.env file).
PS. The most hemorrhoid with containers is the damn file permissions between the host and the container.
I support Anton about https://laradock.io/
I recommend to look/clone my branch https://github.com/dlnsk/laradock/tree/laradock_cl... (it's not very fresh). I made a simple console utility there, which greatly simplifies the launch of artisan, npm, etc. in a container. I created a PR, but the guys don’t itch (they decided to rewrite Go, but they didn’t do anything), but I sit and don’t buzz ...;)
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question