Support for ARG

[yxliang01]

Would be great if bocker can support Dockerfile ARG command!

Thanks

[icy]

@yxliang01 ARG is a new instruction that wasn't available when I started to write Bocker (IMHO). Is that similar to ENV but that's only used at build-time? Is there any real usage example of ARG? Thx a lot.

[yxliang01]

@icy Yes. Your understand is correct. And the most common use case of it, I believe, is ARG DEBIAN_FRONTEND=noninteractive. While many people setting DEBIAN_FRONTEND using ENV, this is not 100% correct. Because later when you run the container interactive mode, the environment variable remains but under that situation, it's not noninteractive anymore.

Thanks!

[icy]

@yxliang01 I got it. thx for your explanation.

The primary movitation of Bocker is to enclose (almost) everything by using Bash routines. It's pretty not easy to do/understand this at first, so let me start with a real case. For example, you want to build nginx-1.3.1. You define version as below

ENV NGINX_VERSION 1.3.1
RUN <build_stuff>

This is cool, until you want to extend your Dockerfile and build next version 1.3.2 . New docker resolves this by introduce ARG and build time environment variables. I see this way is just broken and/or at least not very convenient. My bocker way is as below

## Define nginx.Bockerfile
# define a method to enclose build environment
ed_my_env() {
  export NGINX_VERSION=1.3.1
  export ANOTHER_VAR=foo
}

# Now build and use them
ed_nginx_build() {
   ed_my_env
   # actual build stuff...
}

Now if you want to build new version, you simply use monkey-patching:

ed_reuse nginx.Bockerfile
ed_my_env() {
  export NGINX_VERSION=1.3.2
  export ANOTHER_VAR=bar
}

That's it you don't have to provide any further stuff.

Now back to your original problem. I understand the use of ARG and I think it's useful, however I will need to see if that's too much for bocker. Seriously :) In the mean time, you can always use the raw command as below

echo "ARG FOO=BAR"

This just prints the output immediately and (unfortunately) may make the final Dockerfile output ugly :) To be specific, the output is at the very beginning of the output. To avoid this you can put them inside the definition of ed_bocker

ed_bocker() {
  echo "ARG FOO=BAR"
  ed_group ...
}

This is a little better

[icy]

A real example for btsync image: https://github.com/icy/docker/blob/master/bocker/Bockerfile.btsync14

[yxliang01]

I see. I didn't know what I can just echo out raw Dockerfile command. However, I didn't see how your example relate to the case here though. @icy

[icy]

@yxliang01 :) it's ok. I will have support for ARG quickly. It's almost the same as LABEL so you may take a look. Btw, maybe you help to test if the multiple labels/args are working well, e.g, ed_label foo1=bar1 foo2=bar2. In the original design, bocker likes to work with single declaration due to some natural limitation of bash .

I onced asked why I should use bocker instead of the native Dockerfile. That was a question in a job interview. I admitted that I couldn't explain my ideas well. Only could I say that I am always writing my stuff in bocker ;)

[yxliang01]

Haha. Actually, I'm not using bocker yet but planned to for modularizing my big Dockerfiles. I see the capability of being able to reuse parts of Dockerfile as the bigger advantage. And, I guess the biggest risk might be that, if bocker is unmaintained, either the users need to give up on them or they need to maintain themselves, so that new Dockerfile format or command can be used while we all know that docker is being developed in a very fast pace. And, thanks for making bocker! :) Meanwhile, I'm curious whether you got your job at that time :joy: .

[icy]

I know there are many short Dockerfiles, but as serious shell (Bash) user I really dislike some ideas in Dockerfile syntax. And, I believe that Dockerfile should/can be generated (this is the next level of automation). As Dockerfile focuses on the final image, I don't see it would have some kind of include ability in a near future. What bocker tries to solve, is to generate Dockerfile files. I think this is quite different problems.

As any other open source project, I keep taking a look at this project as long as I'm alive :) To resolve the broken issue, we can always have a way to write a human-readable Dockerfile from Bockerfile (now it's all about base64 strings with verbose definitions in the comment blocks.)

But I think the current bocker has a great problem: its syntax/convention is magic. It was my mistake when I developed the script in the past. I think it's better to have the following syntax (or sth like that)

% reuse base1.bocker
% reuse base2.bocker
% source base3.bocker

% build time

env foo1=bar1
env foo2=bar2
my_func1() { echo "Something"; }
my_func2() { echo "Something"; }

group my_func1 my_func2
group my_func3 my_func4

% run time

env foo1=bar11
env foo2=bar22

port 53/tcp
port 80
port 53/udp

my_func1() { echo "Something"; }
my_func2() { echo "something"; }

create_configuration
create_some_directory
switch_to_some_user
start_a_daemon

That's to say, I really like to keep the current script (branch) stable as much as possible. The next generation development would come with a new sexy and powerful syntax :)

If you have any ideas, pls let me know. I think the current bocker is still good for you, except it may not have some "new" Docker instructions. You may take a look at examples I wrote for my past companies from here https://github.com/icy/docker/tree/fluentd/bocker (I used a lot of HERE_DOCUMENTs)

Regarding the job interview: I couldn't get that job but I am not sure whether it's because of my bocker explanation. It's often said it's a matching problem :dancer: