8 ms·

docker compose is unnecessarily nerfed for using in development. I swear every company I work with has this problem and I always end up carrying along my hybrid

• jayd16 4y ago
  So whats the complaint? Compose seems pretty easy to work with to me.
  • kh_hk 4y ago
    For me the problem is that yaml (and the compose specificatio n) is not self sufficient to support complex scenarios. You will start by setting things and discovering that ENV vars * on the global scope of the compose specification are not supported so you end up having to template and output yaml. Try having 40 microservices and quickly iterate between fixing bugs in them. Some you want mounted, others you want running unmounted. I understand the premise is already broken, you do not want 40 microservices, but that's not a precondition you can fix without a time machine. [[* EDIT: by env vars on the global scope, I mean setting things on the global scope by using an env var, say, you want a certain volume named after an environment variable. You can only use ENVs as values. # this works foo: "${SOME_ENV}" # this does not ${SOME_ENV}: "foobar"
    • itintheory 4y ago
      Your problem is that you can't set ENV variables at the global level? Have you looked at YAML anchors? Makes things more DRY for longer/complex compose files.
      • kh_hk 4y ago
        That's just the tip of the iceberg. My problem is that YAML is not a turing complete language (and dev environments are usually messy by their nature).
        • terseus 4y ago
          Given that YAML it's a configuration language I'd say that not being turing complete it's a feature, not a bug nor a limitation; I always want my language files to be declarative to not suffer the perils of logic. Edit: Also, I don't see the need for a turing complete language for something like docker compose, if you need something really complex you can always script a docker-compose.yml generator with all the logic and complexity you need.
        • benji-york 4y ago
          You might find Cog (https://nedbatchelder.com/code/cog https://nedbatchelder.com/code/cog) helpful for generating YAML on the fly.
        • SirSavary 4y ago
          When I need a Turing-complete Compose file, I use Pulumi to spin up the Docker containers and wire things together: https://www.pulumi.com/blog/pulumi-and-docker-development-to-production https://www.pulumi.com/blog/pulumi-and-docker-development-to...
    • lazide 4y ago
      This is literally ‘why kubernetes?’
• pkrumins 4y ago
  Docker-compose just works and my team gets shit done. Does your team get shit done? If they do then what are you complaining about? If it hits production then it’s all good!
  • kh_hk 4y ago
    All I am saying is: * docker compose could be better * docker compose does not improve that much * by mixing docker compose with templates you can get complex stuff going, but is not a much advertised feature. Most of the "cool dev tool env" that appear are based on kubernetes, or something that is _not_ docker compose, which makes them difficult to adopt. I would like docker compose to improve on a direction that makes development easier, that's all.
    • pkrumins 4y ago
      gg
• fio_ini 4y ago
  You can accomplish the same thing using environment variables. You can pass them in at build time or deploy time. `ENVIRONMENT=dev docker-compose up` or `docker-compose build --build-arg ENVIRONMENT=dev` and in your case maybe you write some function `find_answer() { something-async ... }; ENVIRONMENT=$(find_answer) docker-compose ...` You can also read in .env files... Which in my opinion is cleaner since you can check the configurations into source control for YAML or .env files which is easier to read than hundreds of lines of bash and it's esoteric syntax. I love bash but I'm just sayin.
  • kh_hk 4y ago
    It's a simple example, maybe too simple to get the point. What I want is to conditionally set things on a yaml file. If you have ever used a templating language, you know this problem services: redis: ... {{ if some_condition }} volumes: bla bla {{ end if }} {{ if some_other_condition }} another_service: ... {{ end if }} volumes: {{ for volume in volumes }} - ... {{ end for }}
    • encryptluks2 4y ago
      Podman allows for Kubernetes templates, so theoretically you could use Helm for this potentially.. otherwise, Minikube on Podman. I wish they had Go templating in the compose files though, that would be rad.
    • fio_ini 4y ago
      no haha I get the point but it's just another example I see someone over engineering a problem where it should be declarative. In what use case would you dynamically provision some arbitrary n number of volumes without knowing the path names to them? for volumes why wouldn't you just use "volume_name:/some/path" ... "another_volume:/another/path" and let docker manage the volume for you? you're going to end up writing in a different file "/some/path,/another/path" so why not just put it in the compose file?Also why wouldn't you just mount the root path and put n paths inside of them instead of making them all volumes? I'm struggling to see that you're use case actually needs such a feature and you're solving a problem for something that's actually broken somewhere else. you're adding some virtual layer that's making things harder to manage or understand because you don't understand all the features of docker compose technology instead of fixing the root of the issue. I'm not convinced that you're "feature" is necessary.