4 ms·

Yes, your are both right, of course you can RUN "useradd ...". But we have often made the experience that we need to run more complex processes during docker bu

by d3ck 8y ago

Yes, your are both right, of course you can RUN "useradd ...". But we have often made the experience that we need to run more complex processes during docker builds (with if...else conditions etc.) resulting in complex Dockerfile RUNs. Bundling and reusing this code in plans/artefacts is very useful. In the end we use docker-build to create our images, of course it's not intended to be a substitution for the great (docker hub) image concept.

dvtrn 8y ago
But we have often made the experience that we need to run more complex processes during docker builds (with if...else conditions etc.) resulting in complex Dockerfile RUNs That's fair, I've come across those types of scenarios as well, but trying to solve them during docker build seems like you're giving yourself, and inheritors of your docker image a lot of unnecessary extra work. Shouldn't those processes be solved independently of the docker daemon, and the results fed to Docker when it's ready for them?
- d3ck 8y ago
  I am not sure if I understand your comment correctly, but we all know that there is a very large range of image requirements. Some of them need to be solved during builds (e.g. sometimes you want to distinguish between dev and production setups), other will be processed during container setup. You are right regarding inheritors. Creating a docker-hub image has differnent requirements than creating images for your private environment.
  - dvtrn 8y ago
    I guess I'm not entirely understanding how the scenarios you bring up to myself and others aren't sufficiently solved in the current Dockerfile implementation, along with other command-line tools that I can use immediately or retrieve trivially. A 'framework' for bash + docker feels a bit anti-pattern-y/or at least the benefits just aren't obvious for the way my team uses Docker presently. That said, if what you've put together has solved problems for your team, maybe it will for others, so don't let my incredulity spoil anyone else's curiosity who reads these comments later.
    - d3ck 8y ago
      In the meantime I have realized that the term "framework" is very missleading... ;) But you're pointing out a crucial point. IMO, the need of many Show-HN solutions is often not fully understandable in the first moment. But when processes and requirements change over time, sometimes these solutions are remembered again and can be a starting point for own ideas. That's one of the reasons why I read HN :) Thank you for your constructive comments!
      - dvtrn 8y ago
        when processes and requirements change over time, sometimes these solutions are remembered again and can be a starting point for own ideas. You have a good point, here. Thanks for the responses and helping me understand your work a bit better!

by d3ck 8y ago

dvtrn 8y ago

But we have often made the experience that we need to run more complex processes during docker builds (with if...else conditions etc.) resulting in complex Dockerfile RUNs That's fair, I've come across those types of scenarios as well, but trying to solve them during docker build seems like you're giving yourself, and inheritors of your docker image a lot of unnecessary extra work. Shouldn't those processes be solved independently of the docker daemon, and the results fed to Docker when it's ready for them?

d3ck 8y ago
I am not sure if I understand your comment correctly, but we all know that there is a very large range of image requirements. Some of them need to be solved during builds (e.g. sometimes you want to distinguish between dev and production setups), other will be processed during container setup. You are right regarding inheritors. Creating a docker-hub image has differnent requirements than creating images for your private environment.
- dvtrn 8y ago
  I guess I'm not entirely understanding how the scenarios you bring up to myself and others aren't sufficiently solved in the current Dockerfile implementation, along with other command-line tools that I can use immediately or retrieve trivially. A 'framework' for bash + docker feels a bit anti-pattern-y/or at least the benefits just aren't obvious for the way my team uses Docker presently. That said, if what you've put together has solved problems for your team, maybe it will for others, so don't let my incredulity spoil anyone else's curiosity who reads these comments later.
  - d3ck 8y ago
    In the meantime I have realized that the term "framework" is very missleading... ;) But you're pointing out a crucial point. IMO, the need of many Show-HN solutions is often not fully understandable in the first moment. But when processes and requirements change over time, sometimes these solutions are remembered again and can be a starting point for own ideas. That's one of the reasons why I read HN :) Thank you for your constructive comments!
    - dvtrn 8y ago
      when processes and requirements change over time, sometimes these solutions are remembered again and can be a starting point for own ideas. You have a good point, here. Thanks for the responses and helping me understand your work a bit better!