Docker for developers z java

Editor's Notes

• #4: Wynalazca branży kontenerowej, lider i innowator Przekształć bezpieczeństwo aplikacji i infrastruktury, przenośność, zwinność i wydajność
• #11: Przemyśleś Docker Swarm czy tutaj ma być?
• #13: https://docs.docker.com/engine/docker-overview/
• #14: https://docs.docker.com/engine/docker-overview/#docker-architecture
• #18: Obrazy składają się z wielu warstw
• #22: save/load -> images Export/import -> container https://tuhrig.de/difference-between-save-and-export-in-docker/ https://docs.docker.com/engine/reference/commandline/save/ https://docs.docker.com/engine/reference/commandline/load/
• #25: Flatten a Docker container So it is only possible to “flatten” a Docker container, not an image. So we need to start a container from an image first. Then we can export and import the container in one line: 1 docker export <CONTAINER ID> | docker import - some-image-name:latest
• #26: Flatten a Docker container So it is only possible to “flatten” a Docker container, not an image. So we need to start a container from an image first. Then we can export and import the container in one line: 1 docker export <CONTAINER ID> | docker import - some-image-name:latest
• #27: -volumes not being used by any container docker volume ls -f dangling=true   docker volume prune   -volumes-from <containerId>   *removing docker rm -v <containerId>   docker volume rm <volumeName>   volume inspect <volumeName>       docker volume create myVolume docker run -dit --name alpine1 -v myVolume:/volume alpine
• #30: docker network create my-network docker network ls docker network inspect mysql_default docker network prune Docker container run … --network my-network
• #31: https://docs.docker.com/network/ Podłączenie kontenera do sieci typu bridge spowoduję, że kontenery będące w tej samej sieci będą się mogły pingować a kontenery będące w innych sieciach już nie. Podłączenie kontenera do sieci none spowoduję, że kontener będzie miał tylko interfejs pętli zwrotnej loopback. Podłączenie kontenera do sieci host powoduję, że będzie on współdzielił porty i adresy IP hosta. https://docs.docker.com/network/bridge/
• #42: FROM <image>:<tag> MAINTAINER WORKDIR ADD <source path or URL> <destination path> (copy the files from the source into the containers) COPY <source path or URL> <destination path> (copy new files of directories>   As you can see, the functionality of COPY is almost the same as the ADD instruction, with one difference. COPY supports only the basic copying of local files into the container. On the other hand, ADD gives some more features, such as archive extraction, downloading files through URL, and so on. Docker's best practices say that you should prefer COPY if you do not need those additional features of ADD. The Dockerfile will be cleaner and easier to understand thanks to the transparency of the COPY command.   RUN CMD command parameter1 parameterN ENTRYPOINT EXPOSEVOLUMELABEL ENV USER ARGONBUILD [144] Let's summarize what we have learned about the differences and their cooperation: A Dockerfile should specify at least one CMD or ENTRYPOINT instruction Only the last CMD and ENTRYPOINT in a Dockerfile will be used ENTRYPOINT should be defined when using the container as an executable You should use the CMD instruction as a way of defining default arguments for the command defined as ENTRYPOINT or for executing an ad-hoc command in a container CMD will be overridden when running the container with alternative arguments ENTRYPOINT sets the concrete default application that is used every time a container is created using the image If you couple ENTRYPOINT with CMD, you can remove an executable from CMD and just leave its arguments which will be passed to ENTRYPOINT The best use for ENTRYPOINT is to set the image's main command, allowing that image to be run as though it was that command (and then use CMD as the default flags)
• #43: FROM <image>:<tag> MAINTAINER WORKDIR ADD <source path or URL> <destination path> (copy the files from the source into the containers) COPY <source path or URL> <destination path> (copy new files of directories>   As you can see, the functionality of COPY is almost the same as the ADD instruction, with one difference. COPY supports only the basic copying of local files into the container. On the other hand, ADD gives some more features, such as archive extraction, downloading files through URL, and so on. Docker's best practices say that you should prefer COPY if you do not need those additional features of ADD. The Dockerfile will be cleaner and easier to understand thanks to the transparency of the COPY command.   RUN CMD command parameter1 parameterN ENTRYPOINT EXPOSEVOLUMELABEL ENV USER ARGONBUILD [144] Let's summarize what we have learned about the differences and their cooperation: A Dockerfile should specify at least one CMD or ENTRYPOINT instruction Only the last CMD and ENTRYPOINT in a Dockerfile will be used ENTRYPOINT should be defined when using the container as an executable You should use the CMD instruction as a way of defining default arguments for the command defined as ENTRYPOINT or for executing an ad-hoc command in a container CMD will be overridden when running the container with alternative arguments ENTRYPOINT sets the concrete default application that is used every time a container is created using the image If you couple ENTRYPOINT with CMD, you can remove an executable from CMD and just leave its arguments which will be passed to ENTRYPOINT The best use for ENTRYPOINT is to set the image's main command, allowing that image to be run as though it was that command (and then use CMD as the default flags)