Now that were environment variables,
which we set up at runtime
with the Docker run command,
and they can be very useful as you saw.
Now what are build-time arguments?
With those, we can actually plug in different values
into our Dockerfile,
or into our image when we build that image
without having to hard code these values
into the Dockerfile.
And again, one example in this example here
could be our port number.
Yes, we're now using an environment variable
and therefore this is quite flexible.
But we actually still have one, not really a problem.
But one area of improvement, I would say.
Our default value is still hard coded to 80.
That might make sense
and might not be a problem at all.
But maybe we want to make this default value
flexible as well.
So that when we build the image,
we can actually build the image based on
one and the same unchanged the Dockerfile multiple times
with different default values.
And that's something we can achieve
with build-time arguments.
For that, we could add an argument.
And again, you can add this anywhere, basically,
I will now add it here and simply give that argument a name.
And I will name it, "default_port."
You can also assign a default value here again,
this time with the equal sign, for example,
like this to again, set it to 80.
Now, this argument cannot be used in your code here,
it's not available there, you can only use it
in your Dockerfile.
And even there, you can't use it on every instruction.
You cannot use it on command, for example,
because that's a runtime command in the end,
which is executed when the container starts.
But you can use your arg on all the other instructions.
And therefore we can also use it on the env instruction,
for example, to set the default value
for this environment variable
to default_port like this.
Again, with a $ sign in front of it to tell Docker
that we're referring to some argument
or environment variable with this word here.
So now with that, it's kind of inception.
I'm aware of that.
But now with that,
we can set a dynamic argument which then is set
as a default value for the dynamic environment variable.
Yes, but now we can build our image here
with a name of feedback-node and then a tag
of let's say, web-app.
And they offer we wanna use port 80.
And hence, we don't have to specify anything,
because that's actually the default for our argument here.
So we can just build it like this.
But there after, we can build this image again, now,
let's say for the dev tag for development,
and now here, we can set a concrete value for default port
by adding --build-arg,
and then setting default port equal to 8000.
Like this, for example.
And now we're again building an image
on a different tag with a different arg value.
There after this value is locked in.
But now we got two images based on the same Dockerfile,
where we didn't need to change any code.
And yet, we're using a different port number,
which is then used as a default
for the environment variable.
And that's just one example.
But it can be useful to be able
to lock certain values in when you build an image
and to be able to build different images
in a flexible way without having
to change the Dockerfile all the time.
So for now, hit Enter, this is being built.
Enter after we have this image available as well.
Now one note about where you specify args and envs.
As you might have noticed,
it always rerun npm install for me here.
You might of course wanna place arg and env
in a place where you then need it thereafter,
and not place it right at the beginning
of your Dockerfile because these instructions
just like all other instructions,
add layers to your Dockerfile.
And hence, when something changes about them,
all subsequent layers are rebuilt, are re-executed.
So all subsequent instructions are re-executed.
And I don't wanna execute npm install again all the time.
Just because I passed in a different default port argument.
It's not relevant to this command.
So this command shouldn't rerun just because I did that.
That's just an extra note on where to place these things.
But with that, that's it for arguments and environments.
That's how we can use them.
And why they might be useful in certain applications.
We're going to see more of that,
throughout the course, of course.