{"id":1099,"date":"2024-07-29T17:45:49","date_gmt":"2024-07-29T17:45:49","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2024\/07\/29\/how-to-create-dockerfiles-with-genai\/"},"modified":"2024-07-29T17:45:49","modified_gmt":"2024-07-29T17:45:49","slug":"how-to-create-dockerfiles-with-genai","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2024\/07\/29\/how-to-create-dockerfiles-with-genai\/","title":{"rendered":"How to Create Dockerfiles with GenAI\u00a0"},"content":{"rendered":"

This ongoing <\/em>Docker Labs GenAI series<\/em><\/a> will explore the exciting space of AI developer tools. At Docker, we believe there is a vast scope to explore, openly and without the hype. We will share our explorations and collaborate with the developer community in real time. Although developers have adopted autocomplete tooling like GitHub Copilot and use chat, there is significant potential for AI tools to assist with more specific tasks and interfaces throughout the entire software lifecycle. Therefore, our exploration will be broad. We will be releasing things as open source so you can play, explore, and hack with us, too.<\/em><\/p>\n

As we learn how to work more effectively with generative AI, one of the tasks we return to is Dockerfile generation. Because we can equip our AI assistants with tools, does this allow us to reframe the problem of content generation as an interaction between LLMs and tools?<\/p>\n

If you ask ChatGPT to write a Dockerfile<\/a> for your project, it will initiate a conversation with you and ask you to extract some details from your project (Figure 1).<\/p>\n

Figure 1:<\/strong> Asking ChatGPT for help writing a Dockerfile.<\/p>\n

However, we can also equip our assistant with a tool to extract this information from the project directly. Instead of asking the user, an assistant can ask for a tool instead.<\/p>\n

Using tools<\/h2>\n

Here\u2019s an alternative framing. Let\u2019s prompt the assistant with two high-level instructions whenever it is asked to create a Dockerfile.<\/p>\n

\n* First, analyze the project to determine how it should be built.
\n* Once the analysis is complete, create a Dockerfile to build that project.\n<\/div>\n

In addition to these new prompts, we will also supply the LLM with two function definitions.<\/p>\n

\n[{“name”: “analyze_project”,
\n “description”: “Analyze a project to determine how it should be built”},
\n {“name”: “write_files”,
\n “description”: “write a set of files to my project”,
\n “parameters”: {…}}]\n<\/div>\n

With these two functions, the assistant will have enough agency that it can write a Dockerfile directly to a user\u2019s project. Unfortunately, without best practices, the actual Dockerfile content is never very good.\u00a0<\/p>\n

Here\u2019s an example of the kind of Dockerfile that gets generated when the assistant knows the kind of project but not much else.<\/p>\n

\n# Use the official Node.js image from the Docker Hub
\nFROM node:14\n

# Create and change to the app directory
\nWORKDIR \/usr\/src\/app<\/p>\n

# Copy the package.json and package-lock.json files
\nCOPY package*.json .\/<\/p>\n

# Install dependencies
\nRUN npm install<\/p>\n

# Copy the rest of the application code
\nCOPY . .<\/p>\n

# Expose the port your app runs on
\nEXPOSE 3000<\/p>\n

# Define the command to run your app
\nCMD [“npm”, “start”]\n<\/p><\/div>\n

This example shows several standard Dockerfile authoring problems.<\/p>\n

Uses out of date base images.<\/p>\n

Does not employ multi-stage builds.<\/p>\n

Skips newer Docker features such as cache mounts.<\/p>\n

So, what can we do about this? Let\u2019s extract some best practices for authoring NPM project Dockerfiles.<\/p>\n

\nWrite Dockerfiles for NPM projects using three stages. Do these three steps sequentially.
\n* the first node dependencies stage should be called “deps”
\n and it should fetch the runtime dependencies using npm ci
\n with the –omit=dev flag.
\n* The second Dockerfile stage should be called build and it should be based on the deps stage.
\n It should run npm ci and then npm build
\n* The third Dockerfile stage should select a base image
\n that is recommended by Scout and use that in the FROM line.
\n This stage should do then do three things.
\n\t1. it copies the node_modules directory from the deps stage.
\n 2. it copies the dist directory from the build stage.
\n 3. it then runs npm start\n

If you need to use a RUN statement containing npm ci always
\nadd the argument –mount=type=cache,target=\/root\/.npm to the RUN instruction.
\nThe –mount argument should be placed between the word RUN and the npm command.
\nThis will cache the npm packages in the docker build cache and speed up the build process.
\nAfter selecting a base image, get a recommended tag. This recommendation will change over time but start with what is recommended now.\n<\/p><\/div>\n

We\u2019ll include this content in any conversation occurring in the context of an NPM project. We\u2019ll also add a third function.<\/p>\n

\n[{“name”: “docker_scout_tag_recommendation”,
\n “description”: “get a recommended tag”,
\n “parameters”: {…}}]\n<\/div>\n

At the time of writing, here\u2019s the output from our assistant. In this example, the assistant is using the GPT-4 model, but we are seeing the same results with other local models.<\/p>\n

\n# Stage 1 – Downloading dependencies
\nFROM node:22-slim AS deps
\nWORKDIR \/usr\/src\/app
\nCOPY package*.json .\/
\nRUN –mount=type=cache,target=\/root\/.npm npm ci –omit=dev\n

# Stage 2 – Building application
\nFROM deps AS build
\nRUN –mount=type=cache,target=\/root\/.npm npm ci && npm build<\/p>\n

# Stage 3 – Using a recommended base image from Scout
\nFROM node:22-slim
\nWORKDIR \/usr\/src\/app
\nCOPY –from=deps \/usr\/src\/app\/node_modules .\/node_modules
\nCOPY –from=build \/usr\/src\/app\/dist .\/dist
\nCMD [ “npm”, “start” ]\n<\/p><\/div>\n

This is a big improvement. The three inputs that underlie this improvement are listed below.<\/p>\n

The two top-level instructions that anchor the process our assistant should use:<\/p>\n

\n* First, analyze the project to determine how it should be built.
\n* Once the analysis is complete, create a Dockerfile to build that project.\n<\/div>\n

The Markdown content that summarizes our Docker specific best practices.<\/p>\n

The functions (analyze_project, write_files, and docker_scout_tag_recommendation).<\/p>\n

Distilling best practices is certainly not easy, but a little can go a long way.\u00a0Still, it is still hard to know whether this can be considered an improvement over just using code templates. Our continuing investigation centers around whether generative AI will help us to more easily adapt these models to new knowledge, new features, and new project types.<\/p>\n

Conversation loop<\/h3>\n

It\u2019s instructive to go through the actual messages passed between agents here. It\u2019s particularly interesting to look at the interplay between the Assistant and the Tool agents. Near the end of the exchange, there is an unexpected twist where the write_files tool complains that it was passed an invalid JSON file. In this case, the assistant actually did generate invalid JSON and the tool was right to complain. However, the assistant also responded to this error by fixing the JSON and calling the tool a second time! That was unscripted<\/em>.<\/p>\n

Another interesting example of an unscripted moment is the last message from the assistant. The assistant correctly determines that the task is now complete and generates a summary of the work that was done and why.<\/p>\n

Transcript<\/h2>\n

System:<\/strong><\/p>\n

You are an assistant who specializes in authoring Dockerfiles for projects. Since you are an expert and know about their project, be definitive about recommendations.<\/p>\n

User:<\/strong><\/p>\n

First, analyze the project to determine how it should be built.<\/p>\n

Once the analysis is complete, create a Dockerfile to build that project.<\/p>\n

Assistant:<\/strong><\/p>\n

\n[{:function {:arguments “{}” :name “analyze_project”}}]\n<\/div>\n

Tool (analyze_project):<\/strong><\/p>\n

This is an NPM project.<\/p>\n

System:<\/strong><\/p>\n

Write Dockerfiles for NPM projects using three stages. Do these three steps sequentially \u2026<\/p>\n

\u2026<\/p>\n

\u2026 (system prompts excluded for brevity) ..<\/p>\n

\u2026<\/p>\n

Assistant:<\/strong><\/p>\n

\n[{:function {:arguments “{
\n “repository”: “node”
\n}”
\n :name “docker_scout_tag_recommendation”}}]\n<\/div>\n

Tool (docker_scout_tag_recommendation):<\/strong><\/p>\n

22-slim<\/p>\n

Assistant:<\/strong><\/p>\n

\n[{:function {:arguments “{
\n “files”: [
\n {
\n “path”: “Dockerfile”,
\n “content”: `
\n# Stage 1 – the build process
\nFROM node:22-slim AS deps
\nWORKDIR \/usr\/src\/app
\nCOPY package*.json .\/
\nRUN –mount=type=cache,target=\/root\/.npm npm ci –omit=dev
\n# Stage 2 – the production environment
\nFROM deps AS build
\nRUN npm ci && npm run build
\n# Stage 3 – the production environment
\nFROM node:22-slim
\nWORKDIR \/usr\/src\/app
\nCOPY –from=deps \/usr\/src\/app\/node_modules .\/node_modules
\nCOPY –from=build \/usr\/src\/app\/dist .\/dist
\nCMD [ “npm”, “start” ]`,
\n “executable”: false
\n }
\n ]
\n}”
\n :name “write_files”}
\n :id “call_6VVCLiXcIBNyEGPQwftR7xEV”}]\n<\/div>\n

Tool:<\/strong><\/p>\n

function call write_files failed call exited with non-zero code (1):\u00a0 call exited with non-zero code (1): #error {rn :cause Unexpected character (\u2018`\u2019)<\/p>\n

Assistant:<\/strong><\/p>\n

I apologize for the error. Let me try that again.<\/p>\n

\n[{:function {:arguments “{
\n “files”: [
\n {
\n “path”: “Dockerfile”,
\n “content”: “FROM node:22-slim AS deps\\nWORKDIR \/usr\/src\/app\\nCOPY package*.json .\/\\nRUN –mount=type=cache,target=\/root\/.npm npm ci –omit=dev\\n\\nFROM deps AS build\\nRUN npm ci && npm run build\\n\\nFROM node:22-slim\\nWORKDIR \/usr\/src\/app\\nCOPY –from=deps \/usr\/src\/app\/node_modules .\/node_modules\\nCOPY –from=build \/usr\/src\/app\/dist .\/dist\\nCMD [ \\”npm\\”, \\”start\\” ]”,
\n “executable”: false
\n }
\n ]
\n}”
\n :name “write_files”}}]\n<\/div>\n

Tool (write_files):<\/strong><\/p>\n

wrote 1 files: Dockerfile<\/p>\n

Assistant:<\/strong><\/p>\n

I have written the Dockerfile for your NPM project. You can find it in your project folder. This Dockerfile uses a multi-stage build process to efficiently build and run your application within a Docker container. The first stage fetches the runtime dependencies, the second stage builds the application, and the final stage runs the application. Please let me know if you need further assistance.<\/p>\n

Summary<\/h2>\n

For a generative AI assistant to improve its ability to generate Dockerfile content, we have identified both tools and stack-specific best practice content as key enablers. Incorporating these elements into a generative AI based assistant can serve as an alternative to code templates. We continue to evaluate whether this approach allows us to more easily adapt to new project types.<\/p>\n

As always, feel free to follow along in our public repo<\/a> and reach out. Everything we\u2019ve discussed in this blog post is available for you to try on your own projects.<\/p>\n

For more on what we\u2019re doing at Docker, subscribe to our newsletter.<\/a><\/p>\n

Learn more<\/h2>\n

Subscribe to the Docker Newsletter<\/a>.<\/p>\n

Read the Docker Labs GenAI series<\/a>.<\/p>\n

Get the latest release of Docker Desktop<\/a>.<\/p>\n

Vote on what\u2019s next! Check out our public roadmap<\/a>.<\/p>\n

Have questions? The Docker community is here to help<\/a>.<\/p>\n

New to Docker? Get started<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"

This ongoing Docker Labs GenAI series will explore the exciting space of AI developer tools. At Docker, we believe there […]<\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[4],"tags":[],"class_list":["post-1099","post","type-post","status-publish","format-standard","hentry","category-docker"],"_links":{"self":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/1099","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/comments?post=1099"}],"version-history":[{"count":0,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/1099\/revisions"}],"wp:attachment":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media?parent=1099"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/categories?post=1099"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/tags?post=1099"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}