Support for ARG
yxliang01 opened this issue · comments
Would be great if bocker can support Dockerfile ARG
command!
Thanks
@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.
@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!
@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
A real example for btsync image: https://github.com/icy/docker/blob/master/bocker/Bockerfile.btsync14
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
@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
;)
Haha. Actually, I'm not using bocker
yet but planned to for modularizing my big Dockerfile
s. 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 😂 .
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_DOCUMENT
s)
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 💃