4 ms·

Sweet, looks good. I reckon docker and docker-compose have been probably some of the greatest enablers for my development process, and how I think about desigin

by L_226 7y ago

Sweet, looks good. I reckon docker and docker-compose have been probably some of the greatest enablers for my development process, and how I think about desiging software systems.

daveguy 7y ago
Agreed. I was worried docker-compose might be abandoned for swarm-only at the kubernetes level. Compose is a much easier level to develop and work with. Doesn't do all the balancing and HA, but for most projects you don't need that, just good organization of the pieces.
- kalev 7y ago
  This is exactly why we still use compose as well. Everybody is talking about kubernetes, but I honestly don’t see the point in adding a huge dependency only for balancing and restarting failed containers.. I just wish there was some SaaS platform which allows you to upload a docker-compose file and run the containers for you. That way, you don’t have to touch the underlying OS.
  - larrybud 7y ago
    Azure App service lets you do this. https://docs.microsoft.com/en-us/azure/app-service/containers/quickstart-multi-container https://docs.microsoft.com/en-us/azure/app-service/container...
  - tilolebo 7y ago
    The AWS ECS cli has this kind of feature (I never used it) : https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cmd-ecs-cli-compose.html https://docs.aws.amazon.com/AmazonECS/latest/developerguide/... v2 even allows to create the underlying networking resources (VPC), provision an application load balancer, etc.
- jswny 7y ago
  Aren't Compose and Swarm/Stack very similar, but Stack has support for distribution between multiple nodes? I know their actual configurations aren't equivalent, but they are similar (Stack supports config options for distribution, etc.).
cactus2093 7y ago
But on that note, the fact that there isn't a single cross-platform filesystem that works on Windows, MacOS, and Linux has been one of the greatest detractors for a docker-based development environment. The performance of Docker for Mac is often a showstopper for running a big app in docker for development, especially in combination with other slow and i/o heavy tools like webpack. Apparently Apple came very close to using ZFS too, instead of building APFS. Oh what could have been.
- cpuguy83 7y ago
  The performance of the fs is not really related to the container fs (apfs seems like it could be great for a container fs, in theory), but rather the fs being shared across the VM barrier which enables sharing developer-local files with the container.
  - ivan_ah 7y ago
    Since you were able to describe the problem of fs-sharing-for-containers so well, I was wondering if you have any recommendations for a usable cross-platform dev workflow? We're currently using a mix of docker-compose for the service and native development for the main application (requiring separate instructions for win, mac, and linux). I'd love to be able to transition this to a simpler all-docker-compose setup.
    - pas 7y ago
      I fought with this regularly for about a year - on Windows - and recently settled on duplicating almost everything inside the VM and outside it, except the bare shared code I'm working on. Okay, that sounds confusing, I know. We use Vagrant, because you can put every kind of ancient incantations into the Vagrantfile to check for whatever misconfiguration on the host, and so on. Plus you don't have to wrap your app in Docker this way, so debugging becomes a bit easier. Basically we have a fair bit of Ruby in the Vagrantfile setting up a dev env on the host (scoop + pip + poetry) and provision files setting up the env inside the VM. (Let's say a DB + pip + poetry + uWSGI.) This is necessary, because for code completion you want the dependencies accessible for your IDE. (Yes, PyCharm Ultimate Pro Gold Edition has a way to use remote interpreters, but then you need to guarantee that for every dev too, and it's still not as fast as just having the files on the host in a venv.) The VBoxSF shared filesystem has a lot of quirks, so we minimize the shared stuff. (We tried NFS and CIFS/SMB too. Both were amazing disasters.) For NodeJS stuff we only have the runtime dependencies in the VM (database, other backed services), but you have to be careful to script everything in a cross-platform way in package.json (so basically don't script anything there start the NodeJS process as soon as you can, and work inside that). And the provision scripts are simple, because they just setup docker containers. Usually without compose, because meh, it's easier to just type a few lines of Bash to rm -f the container and run a new one, and maintaining a useful compose file is unnecessary at that point.
rabuse 7y ago
I use docker compose, along with swarm, for multiple services. I love being able to manage/deploy a stack with them.

by L_226 7y ago

Sweet, looks good. I reckon docker and docker-compose have been probably some of the greatest enablers for my development process, and how I think about desiging software systems.

daveguy 7y ago

Agreed. I was worried docker-compose might be abandoned for swarm-only at the kubernetes level. Compose is a much easier level to develop and work with. Doesn't do all the balancing and HA, but for most projects you don't need that, just good organization of the pieces.

kalev 7y ago
This is exactly why we still use compose as well. Everybody is talking about kubernetes, but I honestly don’t see the point in adding a huge dependency only for balancing and restarting failed containers.. I just wish there was some SaaS platform which allows you to upload a docker-compose file and run the containers for you. That way, you don’t have to touch the underlying OS.
- larrybud 7y ago
  Azure App service lets you do this. https://docs.microsoft.com/en-us/azure/app-service/containers/quickstart-multi-container https://docs.microsoft.com/en-us/azure/app-service/container...
- tilolebo 7y ago
  The AWS ECS cli has this kind of feature (I never used it) : https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cmd-ecs-cli-compose.html https://docs.aws.amazon.com/AmazonECS/latest/developerguide/... v2 even allows to create the underlying networking resources (VPC), provision an application load balancer, etc.
jswny 7y ago
Aren't Compose and Swarm/Stack very similar, but Stack has support for distribution between multiple nodes? I know their actual configurations aren't equivalent, but they are similar (Stack supports config options for distribution, etc.).

cactus2093 7y ago

But on that note, the fact that there isn't a single cross-platform filesystem that works on Windows, MacOS, and Linux has been one of the greatest detractors for a docker-based development environment. The performance of Docker for Mac is often a showstopper for running a big app in docker for development, especially in combination with other slow and i/o heavy tools like webpack. Apparently Apple came very close to using ZFS too, instead of building APFS. Oh what could have been.

cpuguy83 7y ago
The performance of the fs is not really related to the container fs (apfs seems like it could be great for a container fs, in theory), but rather the fs being shared across the VM barrier which enables sharing developer-local files with the container.
- ivan_ah 7y ago
  Since you were able to describe the problem of fs-sharing-for-containers so well, I was wondering if you have any recommendations for a usable cross-platform dev workflow? We're currently using a mix of docker-compose for the service and native development for the main application (requiring separate instructions for win, mac, and linux). I'd love to be able to transition this to a simpler all-docker-compose setup.
  - pas 7y ago
    I fought with this regularly for about a year - on Windows - and recently settled on duplicating almost everything inside the VM and outside it, except the bare shared code I'm working on. Okay, that sounds confusing, I know. We use Vagrant, because you can put every kind of ancient incantations into the Vagrantfile to check for whatever misconfiguration on the host, and so on. Plus you don't have to wrap your app in Docker this way, so debugging becomes a bit easier. Basically we have a fair bit of Ruby in the Vagrantfile setting up a dev env on the host (scoop + pip + poetry) and provision files setting up the env inside the VM. (Let's say a DB + pip + poetry + uWSGI.) This is necessary, because for code completion you want the dependencies accessible for your IDE. (Yes, PyCharm Ultimate Pro Gold Edition has a way to use remote interpreters, but then you need to guarantee that for every dev too, and it's still not as fast as just having the files on the host in a venv.) The VBoxSF shared filesystem has a lot of quirks, so we minimize the shared stuff. (We tried NFS and CIFS/SMB too. Both were amazing disasters.) For NodeJS stuff we only have the runtime dependencies in the VM (database, other backed services), but you have to be careful to script everything in a cross-platform way in package.json (so basically don't script anything there start the NodeJS process as soon as you can, and work inside that). And the provision scripts are simple, because they just setup docker containers. Usually without compose, because meh, it's easier to just type a few lines of Bash to rm -f the container and run a new one, and maintaining a useful compose file is unnecessary at that point.

rabuse 7y ago

I use docker compose, along with swarm, for multiple services. I love being able to manage/deploy a stack with them.