@@ -461,6 +461,47 @@ Similar to having constant variables in a program (as opposed to hard-coding
461
461
values), this approach lets you change a single ` ENV ` instruction to
462
462
auto-magically bump the version of the software in your container.
463
463
464
+ Each ` ENV ` line creates a new intermediate layer, just like ` RUN ` commands. This
465
+ means that even if you unset the environment variable in a future layer, it
466
+ still persists in this layer and its value can be dumped. You can test this by
467
+ creating a Dockerfile like the following, and then building it.
468
+
469
+ ``` Dockerfile
470
+ FROM alpine
471
+ ENV ADMIN_USER="mark"
472
+ RUN echo $ADMIN_USER > ./mark
473
+ RUN unset ADMIN_USER
474
+ CMD sh
475
+ ```
476
+
477
+ ``` bash
478
+ $ docker run --rm -it test sh echo $ADMIN_USER
479
+
480
+ mark
481
+ ```
482
+
483
+ To prevent this, and really unset the environment variable, use a ` RUN ` command
484
+ with shell commands, to set, use, and unset the variable all in a single layer.
485
+ You can separate your commands with ` ; ` or ` && ` . If you use the second method,
486
+ and one of the commands fails, the ` docker build ` also fails. This is usually a
487
+ good idea. Using ` \ ` as a line continuation character for Linux Dockerfiles
488
+ improves readability. You could also put all of the commands into a shell script
489
+ and have the ` RUN ` command just run that shell script.
490
+
491
+ ``` Dockerfile
492
+ FROM alpine
493
+ RUN export ADMIN_USER="mark" \
494
+ && echo $ADMIN_USER > ./mark \
495
+ && unset ADMIN_USER
496
+ CMD sh
497
+ ```
498
+
499
+ ``` bash
500
+ $ docker run --rm -it test sh echo $ADMIN_USER
501
+
502
+ ```
503
+
504
+
464
505
### ADD or COPY
465
506
466
507
- [ Dockerfile reference for the ADD instruction] ( /engine/reference/builder.md#add )
0 commit comments