![Concerns: Build vs Runtime
1. FROM debian:jessie
# ==> Install build tools...
2. RUN apt-get update
3. RUN apt-get install -y make gcc
# ==> Compile, and install...
4. COPY . /buildContext
WORKDIR /buildContext/redis
5. RUN make
6. RUN make install
# ==> Clean up...
7. RUN apt-get remove -y --auto-remove make gcc
8. RUN apt-get clean
9. RUN rm -rf /var/lib/apt/lists/* /buildContext
# ==> Execute…
WORKDIR /
ENTRYPOINT ["redis-server"]
1. FROM debian:jessie
2. COPY . /buildContext
3. RUN apt-get update
&& apt-get install -y make gcc
# ==> Compile, and install...
&& cd /buildContext/redis
&& make
&& make install
# ==> Clean up...
&& apt-get remove -y --auto-remove make gcc
&& apt-get clean
&& rm -rf /var/lib/apt/lists/* /buildContext
# ==> Execute…
WORKDIR /
ENTRYPOINT ["redis-server"]
Build Friendly Runtime Friendly](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
What's hot
What's hot (19)
Viewers also liked
Viewers also liked (19)
Similar to Rule of two
Similar to Rule of two (20)
Recently uploaded
Recently uploaded (20)
Rule of two
- 1. Rule of Two
- 2. Concerns: Build vs Runtime 1. FROM debian:jessie # ==> Install build tools... 2. RUN apt-get update 3. RUN apt-get install -y make gcc # ==> Compile, and install... 4. COPY . /buildContext WORKDIR /buildContext/redis 5. RUN make 6. RUN make install # ==> Clean up... 7. RUN apt-get remove -y --auto-remove make gcc 8. RUN apt-get clean 9. RUN rm -rf /var/lib/apt/lists/* /buildContext # ==> Execute… WORKDIR / ENTRYPOINT ["redis-server"] 1. FROM debian:jessie 2. COPY . /buildContext 3. RUN apt-get update && apt-get install -y make gcc # ==> Compile, and install... && cd /buildContext/redis && make && make install # ==> Clean up... && apt-get remove -y --auto-remove make gcc && apt-get clean && rm -rf /var/lib/apt/lists/* /buildContext # ==> Execute… WORKDIR / ENTRYPOINT ["redis-server"] Build Friendly Runtime Friendly
- 3. Build Friendly Runtime Friendly 1. FROM debian:jessie 1. 1. 2. RUN apt-get update 3. RUN apt-get install –y … 4. COPY . /buildContext 5. RUN make 6. RUN make install 7. RUN apt-get remove … 8. RUN apt-get clean 9. RUN rm -rf /../lists/* … 3. 2,3,5-9 2. 4
- 4. “…neither can live while the other survives!”
- 5. docker build --squash • Long History: #332 - 4/2013, #3116 - 12/2013, #6906 -7/2014, #12198 - 4/2015, … • Pull request #22641: • Merges N physical layers into single one. • Eliminates logically deleted files. • How to decide which layers to preserve?
- 6. “Always two there are, no more, no less.” Runtime Friendly = Microservice Service Service Service Service Service Service Service Service Service Service Service Service Application Dependencies . . . Dependency Layer Service Layer Service layer Depend layer Service layer Depend layer Service layer Depend layer Service layer Depend layer Service layer Depend layer Service layer Depend layer Service layer Depend layer Service layer Depend layer Application …
- 7. Build Friendly Runtime Friendly 1. FROM debian:jessie 1. 1. 2. RUN apt-get update 3. RUN apt-get install –y … 4. COPY . /buildContext 5. RUN make 6. RUN make install 7. RUN apt-get remove … 8. RUN apt-get clean 9. RUN rm -rf /../lists/* … 2-9 docker build --squash
- 8. Build Friendly Runtime Friendly docker buld --squash
- 9. Summary • A runtime image (microservice) consists of only 2 logical layers. • --squash option can enforce “Rule of 2”. • Although experimental, --squash will almost certainly be publically available in next release. • Future Dockerfile features will hopefully obsolesce --squash.
Editor's Notes
- Notable Accomplishment: OOBash = Python. October Build VS Runtime
- Dockerfiles redis image showing Build Friendly vs. Runtime Friendly. Instruction numbering represents layer production. Implicit Commit performed after every Dockerfile command. A layer preserves any files committed to it. A build cache is simply a set of layers that preserve artifacts created by build tooling. A Build Friendly Dockerfile maximizes the number of layers within the build cache to improve cache utility by isolating operations that affect state to as few layers as possible. Build Friendly Dockerfiles speed development but slow deployment/dangerous increase attack surface. A Runtime Friendly Dockerfile minimizes layer creation to physically eliminate build artifacts from the image. It does so by aggregating operations that both create and delete build artifacts within the same Dockerfile command so they’re performed before committing a new layer. This speeds deployment and reduces runtime attack surface but adds friction to development builds as it negates the benefits of caching. Step through example. For example Build Friendly – Steps 1-3 are bypassed during a subsequent build of redis due to changes in redis source code.
- Why minimal images important? Bandwidth costs Speed Security
- Optimizing for one diminishes the other!
- Mentioned by Arun Gupta 31K range Aufs limit 42 – 127, Commit, Mark Squash Provide opinion and rational?
- Left Monolith = static binding of services Service – public interface/protocol business domain specific functions – like calculate contractor paycheck. Dependency – supporting functions apply a technology stacked technology http client & server Right Application – emerges from dynamically coupled microservices Reuse Runtime Layers? Dynamic binding. Dependency layer Static bindings, may be used Monolith what is it really? Optimized container network. Coupled oscillator
- Merges all layers up to but not including the base image. See <none><none> Runtime Friendly gets tagged – Build friendly doesn’t
- Who is satisfied with this solution enough to cease searching for another one? Don’t mind writing cleanup code? How to fix it? Potential better method?