Do you work with docker and docker-compose?

Do you work with docker and docker-compose?

tom

Creator of StickerRun®
Community Team
Local time
16:41
Joined
Oct 13, 2019
Messages
258

Hi everyone!

Are you working with Docker and/or docker-compose?
If so, do you have a central storage for your docker-compose files?

I'm thinking about creating a little website for your docker-compose files.
There have been already a few projects that wanted to provide such things, but that was back in 2016+ and none of those is online anymore.

Looking forward to hearing from you!

 

fbnlsr

Member
Local time
16:41
Joined
Oct 13, 2019
Messages
78

Shouldn't the docker-compose file be stored alongside the project's files?

I'm in the process of learning Docker. I thought I'd just leave the docker-compose file in my git repo. Is that a bad idea?

 

Gummibeer

Astroneer
Moderator
Local time
16:41
Joined
Oct 5, 2019
Messages
1,167
Pronouns
he/him

Shouldn't the docker-compose file be stored alongside the project's files?

I'm in the process of learning Docker. I thought I'd just leave the docker-compose file in my git repo. Is that a bad idea?

We do it that way. Same for custom docker files. This enables us to have code and image changes in the same repo, PR and don't have to guess why something was added/removed.

 

nick

Member
Gold Member
Local time
07:41
Joined
Oct 13, 2019
Messages
42
Pronouns
he/him

In my experience, docker-compose files are pretty unique to the project the live alongside.

Or do you plan on having directory of one-click docker apps with multiple components which run using docker compose?

Simply download the yaml file and run docker-compose up

 

tom

Creator of StickerRun®
Community Team
Local time
16:41
Joined
Oct 13, 2019
Messages
258

@nick yeah it would be something like that. Definitely the right direction. It would be a combination of a public directory and a private hosting service. Depends on what you are going to do with your docker-compose files.

 

Gummibeer

Astroneer
Moderator
Local time
16:41
Joined
Oct 5, 2019
Messages
1,167
Pronouns
he/him

But what's the benefit of having the compose file in another service instead of the repo it belongs to? 🤔

Or is it more of a copy'n'paste and learn ground?

 

tom

Creator of StickerRun®
Community Team
Local time
16:41
Joined
Oct 13, 2019
Messages
258

Knowledge sharing, separation of code, paste bin, ... I've got my docker-compose files separated from code as we've got a few developers who don't want to work with docker or have their own local setups (eg. MAMP). So there's eg. a project-docker repo and a project-laravel repo. Both holding different things. The project-docker repo could be omitted by using this new service.

 

Gummibeer

Astroneer
Moderator
Local time
16:41
Joined
Oct 5, 2019
Messages
1,167
Pronouns
he/him

For me it sounds like the whole opposite what docker is about!? 😲🤔
Why should/can a developer decide in which setup he developes a project? Docker was made to prevent exactly this - different environments and "on my local machine it works".

 

tom

Creator of StickerRun®
Community Team
Local time
16:41
Joined
Oct 13, 2019
Messages
258

Yes, that's right and I'm aware of this. But I'm not in a position where I want to force our devs to use what they don't know yet. We're taking small steps and some frontend devs don't want to have a full blown docker setup when they can use

Bash:
php artisan serve
as soon as they need the backend. 🤷‍♂️
Developers are still humans and forcing them into a direction they don't want to go does not benefit anyone and makes working as a team harder. We have basic agreements and share config files, so eg. the php.ini looks the same on all dev machines and testing stages, same for the apache/nginx/caddy configs. They are defined at the beginning of the project and then shared with all devs.

I know that docker is the perfect fit for this scenario, but I'm not in the position to enforce this. 😅

 

fbnlsr

Member
Local time
16:41
Joined
Oct 13, 2019
Messages
78

Developers are still humans and forcing them into a direction they don't want to go does not benefit anyone and makes working as a team harder.

Not trying to sound like a douche but to me that seems super counter-intuitive. Developers are developers and some decisions are made at the team level and some things have to be enforced. Be it the development environment, build system, commit messages, bug reports, editor configs, git flow, etc... People can chose their environment (OS, code editor, browser of choice), but regarding the project things must be 100% transparent. When people start to do their own thing, it leads to friction and time loss in my experience.

Docker is indeed the perfect fit for this scenario. It helps with continuity as well as team scale. When a new dev comes along, he just has to run git pull / npm install / docker-compose up and he should be ready to go. Now I know I'm basically echoing what others have said before me, but I'm surprised it didn't bite your team once or twice. Also, if people run their own environment, why don't they just ignore the docker-compose file? In the end, to them, it's just a useless config file?

 

tom

Creator of StickerRun®
Community Team
Local time
16:41
Joined
Oct 13, 2019
Messages
258

Don‘t get me wrong. If I could, I would dockerize the world (as far as it makes sense) as it makes working much easier. But the projects the team is working on have already been there when I started. I just repeated the steps that they were doing. I‘m already dockerizing everything I have to be on the secure side.
And again I‘m not in the position to enforce this as I‘m neither the project owner nor lead dev nor technical advisor. I can show them how it may work and make working easier, but after all there are people above me who decide how it‘s done.

 

Gummibeer

Astroneer
Moderator
Local time
16:41
Joined
Oct 5, 2019
Messages
1,167
Pronouns
he/him

100% agree with @fbnlsr ! I also sometimes use the local PHP - because it's faster to run a simple console command with local PHP instead of booting docker and run it via docker-compose. But this use is very limited. We have different PHP versions and extensions over the projects, we have different DBs over the projects and the frontend is the worst. Webpack, gulp, grunt, npm, yarn, node - everything present in any project and everywhere a different version. It's impossible to keep up with it. And where's the problem to run docker-compose up -d instead of php artisan serve? They don't need to understand what happens. That's the difference between devops, backend and frontend.

And I've the experience that the more you enforce and define the less friction you have. There are a lot developers with their opinion, but most of these things aren't this important for them to leave or start a discussion. As long as there's a guideline and in best case a tool that enforces it for them (PHP-CS, StyleCI, PHPMD ...). You get the discussions/friction if it's not defined and everyone reviews by it's own opinion and this starts the discussions.

 

Gummibeer

Astroneer
Moderator
Local time
16:41
Joined
Oct 5, 2019
Messages
1,167
Pronouns
he/him

In this case you should bring up the idea/discussion to the lead-dev/head-of-dev and argue why docker is better, saves time and doesn't bother anyone more because they don't have to understand it. Only run another command.

 

tom

Creator of StickerRun®
Community Team
Local time
16:41
Joined
Oct 13, 2019
Messages
258

Exactly! I‘m making small steps and you can see and feel progress, but it‘s taking time and a few more tries of „running against the wall“ 😁

 
Top