Stefan Oehrli blog post<\/a>.<\/p>\n–squash<\/h3>\n
With the latest versions of docker, there’s an easy way to flatten all those intermediary images at the end.
\nHere I’ve 18.03 and enabled experimental features:<\/p>\n
\n[root@VM121 docker]# docker info\nContainers: 0\n Running: 0\n Paused: 0\n Stopped: 0\nImages: 8\nServer Version: 18.03.0-ce\nStorage Driver: overlay2\n Backing Filesystem: xfs\n...\n \n[root@VM121 docker]# cat \/etc\/docker\/daemon.json\n{\n \"experimental\": true\n}\n<\/code><\/pre>\nI start with the same as before but just add –squash to the build command<\/p>\n
\n[root@VM121 docker]# docker image build --squash -t franck\/demo \/var\/tmp\/demo\n<\/code><\/pre>\nThe output is similar but the image is an additional one, reduced down to the size of my final state (with one 200MB file):<\/p>\n
\n[root@VM121 docker]# docker image ls\nREPOSITORY TAG IMAGE ID CREATED SIZE\nfranck\/demo latest 2ab439a723c4 Less than a second ago 214MB\n<none> <none> c3058e598b0a 3 seconds ago 528MB\nalpine latest 3fd9065eaf02 2 months ago 4.15MB\n<\/code><\/pre>\nThe intermediate image list shows that all was done as without ‘–squash’ but with an additional set which reduced the size:<\/p>\n
\n[root@VM121 docker]# docker image ls -a\nREPOSITORY TAG IMAGE ID CREATED SIZE\nfranck\/demo latest 2ab439a723c4 Less than a second ago 214MB\n<none> <none> c3058e598b0a 3 seconds ago 528MB\n<none> <none> 1f14d93a592e 23 seconds ago 319MB\n<none> <none> 7563d40b650b 27 seconds ago 214MB\n<none> <none> 8ed15a5059bd 28 seconds ago 214MB\n<none> <none> 24b11b9026ce 31 seconds ago 109MB\n<none> <none> 382bb71a6a4a 33 seconds ago 4.15MB\nalpine latest 3fd9065eaf02 2 months ago 4.15MB\n<\/code><\/pre>\nThis step is visible in the image history as a ‘merge’ step:<\/p>\n
\n[root@VM121 docker]# docker image history franck\/demo\nIMAGE CREATED CREATED BY SIZE COMMENT\n2ab439a723c4 Less than a second ago 210MB merge sha256:c3058e598b0a30c606c1bfae7114957bbc62fca85d6a70c2aff4473726431394 to sha256:3fd9065eaf02feaf94d68376da52541925650b81698c53c6824d92ff63f98353\n<missing> 3 seconds ago \/bin\/sh -c dd if=\/dev\/urandom of=file2.100M \u2026 0B\n<missing> 23 seconds ago \/bin\/sh -c mv file1.100M file2.100M 0B\n<missing> 27 seconds ago \/bin\/sh -c rm file0.100M 0B\n<missing> 28 seconds ago \/bin\/sh -c cp file0.100M file1.100M 0B\n<missing> 31 seconds ago \/bin\/sh -c #(nop) ADD file:14cef588b48ffbbf1\u2026 0B\n<missing> 33 seconds ago \/bin\/sh -c #(nop) WORKDIR \/var\/tmp 0B\n<missing> 2 months ago \/bin\/sh -c #(nop) CMD [\"\/bin\/sh\"] 0B\n<missing> 2 months ago \/bin\/sh -c #(nop) ADD file:093f0723fa46f6cdb\u2026 4.15MB\n<\/code><\/pre>\nHowever, even if I have a smaller final image, my filesystem usage is even larger with this additional 210MB:<\/p>\n
\n[root@VM121 docker]# df -hT \/var\/lib\/docker\nFilesystem Type Size Used Avail Use% Mounted on\n\/dev\/sdc xfs 80G 739M 80G 1% \/var\/lib\/docker\n<\/code><\/pre>\nLet’s prune it to get rid of those intermediate images:<\/p>\n
\n[root@VM121 docker]# docker image prune -f\nDeleted Images:\ndeleted: sha256:c3058e598b0a30c606c1bfae7114957bbc62fca85d6a70c2aff4473726431394\ndeleted: sha256:37ed4826d70def1978f9dc0ddf42618d951f65a79ce30767ac3a5037d514f8af\ndeleted: sha256:1f14d93a592eb49a210ed73bf65e6886fcec332786d54b55d6b0e16fb8a8beda\ndeleted: sha256:c65cf4c70aed04e9b57e7a2a4fa454d3c63f43c32af251d8c86f6f85f44b1757\ndeleted: sha256:7563d40b650b2126866e8072b8df92d5d7516d86b25a2f6f99aa101bb47835ba\ndeleted: sha256:31ee5456431e903cfd384b1cd7ccb7918d203dc73a131d4ff0b9e6517f0d51cd\ndeleted: sha256:8ed15a5059bd4c0c4ecb78ad77ed75da143b06923d8a9a9a67268c62257b6534\ndeleted: sha256:6be91d85dec6e1bda6f1c0d565e98dbf928b4ea139bf9cb666455e77a2d8f0d9\ndeleted: sha256:24b11b9026ce738a78ce3f7b8b5d86ba3fdeb15523a30a7c22fa1e3712ae679a\ndeleted: sha256:c0984945970276621780a7888adfde9c6e6ca475c42af6b7c54f664ad86f9c9f\ndeleted: sha256:382bb71a6a4a7ddec86faa76bb86ea0c1a764e5326ad5ef68ce1a6110ae45754\n \nTotal reclaimed space: 524.3MB\n<\/code><\/pre>\nNow having only the squashed image:<\/p>\n
\n[root@VM121 docker]# docker image ls -a\nREPOSITORY TAG IMAGE ID CREATED SIZE\nfranck\/demo latest 2ab439a723c4 32 minutes ago 214MB\nalpine latest 3fd9065eaf02 2 months ago 4.15MB\n \n[root@VM121 docker]# df -hT \/var\/lib\/docker\nFilesystem Type Size Used Avail Use% Mounted on\n\/dev\/sdc xfs 80G 237M 80G 1% \/var\/lib\/docker\n<\/code><\/pre>\nmulti-stage build<\/h3>\n
Finally, you can do something similar to an intermediate squash using multi-stage build.<\/p>\n
Here is my Dockerfile:<\/p>\n
\n FROM alpine:latest as staging\n WORKDIR \/var\/tmp\n ADD file0.100M .\n RUN cp file0.100M file1.100M\n RUN rm file0.100M\n RUN mv file1.100M file2.100M\n RUN dd if=\/dev\/urandom of=file2.100M seek=100 count=100 bs=1M\n \n FROM alpine:latest\n WORKDIR \/var\/tmp\n COPY --from=staging \/var\/tmp .\n<\/code><\/pre>\nWith multi-stage build, we can start the second stage from a different image, and add more steps, but here I just start with the same alpine image and copy the final layer of the previous build.<\/p>\n
We see something very similar to the –squash one:<\/p>\n
\n[root@VM121 docker]# docker image ls\nREPOSITORY TAG IMAGE ID CREATED SIZE\nfranck\/demo latest 55f329385f8c Less than a second ago 214MB\n<none> <none> fd26a00db784 8 seconds ago 528MB\nalpine latest 3fd9065eaf02 2 months ago 4.15MB\n \n[root@VM121 docker]# docker image ls -a\nREPOSITORY TAG IMAGE ID CREATED SIZE\nfranck\/demo latest 55f329385f8c 1 second ago 214MB\n<none> <none> fd26a00db784 9 seconds ago 528MB\n<none> <none> 9bf5be367b63 32 seconds ago 319MB\n<none> <none> 531d78833ba8 35 seconds ago 214MB\n<none> <none> 05dd68114743 36 seconds ago 214MB\n<none> <none> b9e5215a9fc8 39 seconds ago 109MB\n<none> <none> ab332f486793 41 seconds ago 4.15MB\nalpine latest 3fd9065eaf02 2 months ago 4.15MB\n<\/code><\/pre>\nThe history of the last stage shows the copy of 210MB from the previous one:<\/p>\n
\n[root@VM121 docker]# docker image history franck\/demo\nIMAGE CREATED CREATED BY SIZE COMMENT\n55f329385f8c 1 second ago \/bin\/sh -c #(nop) COPY dir:2b66b5c36eff5b51f\u2026 210MB\nab332f486793 41 seconds ago \/bin\/sh -c #(nop) WORKDIR \/var\/tmp 0B\n3fd9065eaf02 2 months ago \/bin\/sh -c #(nop) CMD [\"\/bin\/sh\"] 0B\n<missing> 2 months ago \/bin\/sh -c #(nop) ADD file:093f0723fa46f6cdb\u2026 4.15MB\n<\/code><\/pre>\nThe usage of filesystem is similar to the –squash one. Even if we reduced the final image, all the intermediate states had to be stored:<\/p>\n
\n[root@VM121 docker]# df -hT \/var\/lib\/docker\nFilesystem Type Size Used Avail Use% Mounted on\n\/dev\/sdc xfs 80G 737M 80G 1% \/var\/lib\/docker\n<\/code><\/pre>\nThat looks good, if you accept to use a large intermediate space while building the image, which gives you the possibility to debug without re-running from the beginning, thanks to the layers in cache. However, you have still the inefficiency that each time you try the build, the context will be sent again even when not needed. And that is long with a 3GB .zip in the case of Oracle Database installation. Unfortunately, if you add the file to the .dockerignore once you know you have the ADD steps in cache, the next build attempt will not use the caches anymore. I would love to see a per-stage .dockerignore file for multi-stage builds. Or simply have docker realize that some files in the context will not be needed by the COPY or ADD that are not in cache yet.<\/p>\n
Sending the whole context at each build attempt, when debugging your Dockerfile, is not efficient at all and looks like punch-card time compilation where people sent the cards to be compiled during the night. One syntax error on the first line and you go for another day.<\/p>\n
One solution is to have all the required files in an NFS or HTTPd server and get them with ADD from the URL as mentioned earlier. <\/p>\n
Multi-stage with multi-contexts<\/h3>\n
Another solution is to put all COPY or ADD from context in one Dockerfile to build the image containing all required files, and then build your image from it (and squash it at the end).<\/p>\n
Here is my first Dockerfile, just adding the files from the context:<\/p>\n
\n[root@VM121 docker]# ls \/var\/tmp\/demo\nDockerfile file0.100M nocontext\n[root@VM121 docker]# cat \/var\/tmp\/demo\/Dockerfile\n FROM alpine:latest as staging\n WORKDIR \/var\/tmp\n ADD file0.100M .\n<\/code><\/pre>\nI build this ‘staging’ image:<\/p>\n
\n[root@VM121 docker]# docker image build -t franck\/stage0 \/var\/tmp\/demo\nSending build context to Docker daemon 104.9MB\nStep 1\/3 : FROM alpine:latest as staging\nlatest: Pulling from library\/alpine\nff3a5c916c92: Pull complete\nDigest: sha256:7df6db5aa61ae9480f52f0b3a06a140ab98d427f86d8d5de0bedab9b8df6b1c0\nStatus: Downloaded newer image for alpine:latest\n ---> 3fd9065eaf02\nStep 2\/3 : WORKDIR \/var\/tmp\nRemoving intermediate container 0eeed8e0cfd2\n ---> a5db3b29c8e1\nStep 3\/3 : ADD file0.100M .\n ---> 2a34e1e981be\nSuccessfully built 2a34e1e981be\nSuccessfully tagged franck\/stage0:latest\n<\/code><\/pre>\nThis one is the minimal one:<\/p>\n
\n[root@VM121 docker]# docker image ls\n+ docker image ls\nREPOSITORY TAG IMAGE ID CREATED SIZE\nfranck\/stage0 latest 2a34e1e981be Less than a second ago 109MB\nalpine latest 3fd9065eaf02 2 months ago 4.15MB\n \n[root@VM121 docker]# df -hT \/var\/lib\/docker\nFilesystem Type Size Used Avail Use% Mounted on\n\/dev\/sdc xfs 80G 139M 80G 1% \/var\/lib\/docker\n<\/code><\/pre>\nNow, I don’t need to send this context anymore during further development of my Dockerfile.
\nI’ve added the following steps to a Dockerfile in another directory:<\/p>\n
\n[root@VM121 docker]# ls \/var\/tmp\/demo\/nocontext\/\nDockerfile\n[root@VM121 docker]# cat \/var\/tmp\/demo\/nocontext\/Dockerfile\n FROM franck\/stage0 as stage1\n WORKDIR \/var\/tmp\n RUN cp file0.100M file1.100M\n RUN rm file0.100M\n RUN mv file1.100M file2.100M\n RUN dd if=\/dev\/urandom of=file2.100M seek=100 count=100 bs=1M\n FROM alpine:latest\n WORKDIR \/var\/tmp\n<\/code><\/pre>\nHere is the build, using multi-stage to get a squashed final image (you can also use –squash)<\/p>\n
\n[root@VM121 docker]# docker image build -t franck\/demo \/var\/tmp\/demo\/nocontext\n \nSending build context to Docker daemon 2.048kB\nStep 1\/9 : FROM franck\/stage0 as stage1\n ---> 2a34e1e981be\nStep 2\/9 : WORKDIR \/var\/tmp\nRemoving intermediate container eabf57a8de05\n...\nSuccessfully built 82478bfa260d\nSuccessfully tagged franck\/demo:latest\n<\/code><\/pre>\nAt that point, there’s no advantage on space used as I keep all layers for easy Dockerfile development:<\/p>\n
\n[root@VM121 docker]# df -hT \/var\/lib\/docker\nFilesystem Type Size Used Avail Use% Mounted on\n\/dev\/sdc xfs 80G 738M 80G 1% \/var\/lib\/docker\n \n[root@VM121 docker]# docker image ls\nREPOSITORY TAG IMAGE ID CREATED SIZE\nfranck\/demo latest 82478bfa260d About a minute ago 214MB\n<none> <none> 5772ad68d208 About a minute ago 528MB\nfranck\/stage0 latest 2a34e1e981be About a minute ago 109MB\nalpine latest 3fd9065eaf02 2 months ago 4.15MB\n<\/code><\/pre>\nBut now, if I want to add an additional step:<\/p>\n
\n[root@VM121 docker]# cat >> \/var\/tmp\/demo\/nocontext\/Dockerfile <<< 'RUN chmod a+x \/var\/tmp'\n<\/code><\/pre>\nI can re-build quickly, using cached layers, and without the need to send the context again:<\/p>\n
\n[root@VM121 docker]# docker image build -t franck\/demo \/var\/tmp\/demo\/nocontext\nSending build context to Docker daemon 2.048kB\nStep 1\/10 : FROM franck\/stage0 as stage1\n ---> 2a34e1e981be\nStep 2\/10 : WORKDIR \/var\/tmp\n ---> Using cache\n ---> fa562926cc2b\nStep 3\/10 : RUN cp file0.100M file1.100M\n ---> Using cache\n ---> 31ac716f4d61\nStep 4\/10 : RUN rm file0.100M\n ---> Using cache\n ---> d7392cf51ad9\nStep 5\/10 : RUN mv file1.100M file2.100M\n ---> Using cache\n ---> 4854e503885b\nStep 6\/10 : RUN dd if=\/dev\/urandom of=file2.100M seek=100 count=100 bs=1M\n ---> Using cache\n ---> 5772ad68d208\nStep 7\/10 : FROM alpine:latest\n ---> 3fd9065eaf02\nStep 8\/10 : WORKDIR \/var\/tmp\n ---> Using cache\n ---> a5db3b29c8e1\nStep 9\/10 : COPY --from=stage1 \/var\/tmp .\n ---> Using cache\n ---> 82478bfa260d\nStep 10\/10 : RUN chmod a+x \/var\/tmp\n ---> 4a69ee40a938\nSuccessfully built 4a69ee40a938\nSuccessfully tagged franck\/demo:latest\n<\/code><\/pre>\nOnce I’m ok with my final image, I can remove the intermediate ones:<\/p>\n
\n[root@VM121 docker]# docker image prune -f\nDeleted Images:\ndeleted: sha256:5772ad68d20841197d1424f7c64edd21704e4c7b470acb2193de51ae8741385d\ndeleted: sha256:bab572d749684d126625a74be4f01cc738742f9c112a940391e3533e61dd55b9\ndeleted: sha256:4854e503885b4057809fe2867a743ae7898e3e06b329229519fdb5c9d8b10ac1\ndeleted: sha256:de4acb90433c30d6a21cc3b4483adbd403d8051f3c7c31e6bc095a304606355a\ndeleted: sha256:d7392cf51ad99d5d0b7a1a18d8136905c87bc738a5bc94dec03e92f5385bf9c8\ndeleted: sha256:f037e7f973f4265099402534cd7ba409f35272701166d59a1be8e5e39508b07c\ndeleted: sha256:31ac716f4d61f0048a75b8de6f18757970cf0670a0a3d711e4386bf098b32041\ndeleted: sha256:2dccb363c5beb4daf45586383df6454b198f824d52676f70318444c346c0fe9a\ndeleted: sha256:fa562926cc2b3cb56400e1068984bb4048f56713a3cf6dcfa3cf6d945023ebc4\n \nTotal reclaimed space: 419.4MB\n<\/code><\/pre>\nAnd the staging one:<\/p>\n
\n[root@VM121 docker]# docker image rm franck\/stage0\nUntagged: franck\/stage0:latest\nDeleted: sha256:2a34e1e981be9154c31c5ee7eb942cc121267f4416b6fe502ab93f2dceafd98c\nDeleted: sha256:b996a1bdc829167f16dcbe58b717284764470661c3116a6352f15012e1dff07c\n<\/code><\/pre>\nFinally, I optimized the developement of the Dockerfile and finished with the minimal size.<\/p>\n
\n[root@VM121 docker]# df -hT \/var\/lib\/docker\nFilesystem Type Size Used Avail Use% Mounted on\n\/dev\/sdc xfs 80G 237M 80G 1% \/var\/lib\/docker\n<\/code><\/pre>\nSo what?<\/h3>\n
I’m always surprised by the lack of efficiency when building an image with a Dockerfile. Any serious application deployment involves several intermediate files and the way docker build is layered inflates the size and the time required. Efficient layering and snapshotting work at block level. Here, at file level, any byte of data modified in a file, even metadata such as the file name, is a whole file copy. But for common applications, the installation steps are not as simple adding new files. You may have files appended, object files added to libraries, then compiled, the stripped…<\/p>\n
In this post, I tested some recent features, such as multi-stage build and the experimental –squash, as well as a simple manual multi-stage build. Of course, you can do everything in the same layers, and even not use Dockerfiles at all, but then why using Docker? There’s also the Packer<\/a> approach that I’ve not tested yet. However, I like the Docker approach, but only when used correctly. Deploying an application, like Oracle Database, should use the layered build in the following way: additional steps for new options or new updates. This means that the files must be built elsewhere, in a staging container, and added in one step. And to be efficient, the context should be sent only when needed: when a non-cached ADD or COPY requires it.<\/p>\n","protected":false},"excerpt":{"rendered":"By Franck Pachot . I see increasing demand to build a Docker image for the Oracle Database. But the installation process for Oracle does not really fit the Docker way to install by layers: you need to unzip the distribution, install from it to the Oracle Home, remove the things that are not needed, strop […]<\/p>\n","protected":false},"author":27,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[59],"tags":[601,96,1171],"type_dbi":[],"class_list":["post-11055","post","type-post","status-publish","format-standard","hentry","category-oracle","tag-docker","tag-oracle","tag-oracle-19c"],"acf":[],"yoast_head":"\n
Docker: efficiently building images for large software - dbi Blog<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/docker-efficiently-building-images-for-large-software\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Docker: efficiently building images for large software\" \/>\n<meta property=\"og:description\" content=\"By Franck Pachot . I see increasing demand to build a Docker image for the Oracle Database. But the installation process for Oracle does not really fit the Docker way to install by layers: you need to unzip the distribution, install from it to the Oracle Home, remove the things that are not needed, strop […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/docker-efficiently-building-images-for-large-software\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2018-03-31T14:30:56+00:00\" \/>\n<meta name=\"author\" content=\"Oracle Team\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Oracle Team\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"21 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/docker-efficiently-building-images-for-large-software\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/docker-efficiently-building-images-for-large-software\/\"},\"author\":{\"name\":\"Oracle Team\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"headline\":\"Docker: efficiently building images for large software\",\"datePublished\":\"2018-03-31T14:30:56+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/docker-efficiently-building-images-for-large-software\/\"},\"wordCount\":1455,\"commentCount\":0,\"keywords\":[\"Docker\",\"Oracle\",\"Oracle 19c\"],\"articleSection\":[\"Oracle\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/docker-efficiently-building-images-for-large-software\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/docker-efficiently-building-images-for-large-software\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/docker-efficiently-building-images-for-large-software\/\",\"name\":\"Docker: efficiently building images for large software - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"datePublished\":\"2018-03-31T14:30:56+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/docker-efficiently-building-images-for-large-software\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/docker-efficiently-building-images-for-large-software\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/docker-efficiently-building-images-for-large-software\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Docker: efficiently building images for large software\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\",\"name\":\"Oracle Team\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"caption\":\"Oracle Team\"},\"url\":\"https:\/\/www.dbi-services.com\/blog\/author\/oracle-team\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Docker: efficiently building images for large software - dbi Blog","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/docker-efficiently-building-images-for-large-software\/","og_locale":"en_US","og_type":"article","og_title":"Docker: efficiently building images for large software","og_description":"By Franck Pachot . I see increasing demand to build a Docker image for the Oracle Database. But the installation process for Oracle does not really fit the Docker way to install by layers: you need to unzip the distribution, install from it to the Oracle Home, remove the things that are not needed, strop […]","og_url":"https:\/\/www.dbi-services.com\/blog\/docker-efficiently-building-images-for-large-software\/","og_site_name":"dbi Blog","article_published_time":"2018-03-31T14:30:56+00:00","author":"Oracle Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Oracle Team","Est. reading time":"21 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/docker-efficiently-building-images-for-large-software\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/docker-efficiently-building-images-for-large-software\/"},"author":{"name":"Oracle Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"headline":"Docker: efficiently building images for large software","datePublished":"2018-03-31T14:30:56+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/docker-efficiently-building-images-for-large-software\/"},"wordCount":1455,"commentCount":0,"keywords":["Docker","Oracle","Oracle 19c"],"articleSection":["Oracle"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/docker-efficiently-building-images-for-large-software\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/docker-efficiently-building-images-for-large-software\/","url":"https:\/\/www.dbi-services.com\/blog\/docker-efficiently-building-images-for-large-software\/","name":"Docker: efficiently building images for large software - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2018-03-31T14:30:56+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/docker-efficiently-building-images-for-large-software\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/docker-efficiently-building-images-for-large-software\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/docker-efficiently-building-images-for-large-software\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Docker: efficiently building images for large software"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee","name":"Oracle Team","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","caption":"Oracle Team"},"url":"https:\/\/www.dbi-services.com\/blog\/author\/oracle-team\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/11055","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/27"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=11055"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/11055\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=11055"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=11055"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=11055"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=11055"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}