Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Defence Against the Docker Arts

blog.heroku.com

Post reply on HN
Print view View original

1–10 of 103 posts

Re: Defence Against the Docker Arts

#3

Post by jrockway »

I've been very close to creating something like this internally. It is easy to write a Dockerfile that produces a compact and optimal container. But it's the same lines of code over and over again. Anything we have that's a static site looks like:

    FROM node:10 AS build
    WORKDIR /foo
    COPY . .
    RUN npm i
    RUN npx webpack

    FROM nginx:whatever
    COPY nginx.conf /etc/nginx/config.d/
    COPY --from=build /foo/dist /srv
    ...
It's fine when you have one. Annoying when you have a couple. This isn't code that needs to be checked into the repository and updated. It needs to just work.

The other thing I'd like to see is the ability to output multiple containers from one Dockerfile. There is so much wasted work where I have webpack stuff and a go application that run in separate containers but are built together. There is one Dockerfile like the above to build the static part. There is another to build the go binary and copy it to an almost-pristine alpine container (including dumb-init, cacerts, tzdata, and grpc_health_probe). I don't understand why I have to have two Docker files to do that.

Re: Defence Against the Docker Arts

#4

Post by jtwaleson »

I've always felt that buildpacks in Heroku / Cloud Foundry are the way to go as they offer a higher level of abstraction than Docker files. The resulting containers are often production ready with good default settings. In docker you are re-inventing the wheel more often than not.

Re: Defence Against the Docker Arts

#7

Post by chusk3 »

jrockway wrote: post #3

I've been very close to creating something like this internally. It is easy to write a Dockerfile that produces a compact and optimal container. But it's the same lines of code over and over again. Anything we have that's a static site looks like: FROM node:10 AS build WORKDIR /foo COPY . . RUN npm i RUN npx webpack FROM nginx:whatever COPY nginx.conf /etc/nginx/config.d/ COPY --from=build /foo/dist /srv ... It's fin…

You don't have to have separate dockerfiles. If you use multistage builds, you can name the specific terminal stages and then invoke them with 'docker build -t stagename', which will reuse the build cache as you'd expect. I've done this to export multiple app containers from a monorepo.

Re: Defence Against the Docker Arts

#8

Post by benbristow »

I love the fact Heroku have open-sourced their buildpacks. Dokku takes great use of these and provides a very similar platform to themselves that you can host yourself (DigitalOcean even provide a base-image that will pre-configure Dokku for you). Great for personal websites and the like.

If you want to scale in a pinch then it's a case of making some tiny tweaks and pushing to Heroku instead.

Re: Defence Against the Docker Arts

#9

Post by caust1c »

It's not a case of buildpacks vs dockerfiles. They both solve different problems with different solutions.

Buildpacks fit nicely into the heroku way of doing things. But at any medium to large sized engineering organization, there's no way they could satisfy the requirements for even a simple majority of services that using a Dockerfile provides.

Re: Defence Against the Docker Arts

#10

Post by zapita »

Here’s a little known fact: “docker build” can trivially be extended to build buildpacks or CNB. Now that the buildkit refactoring is complete, Dockerfiles are just the default frontend. There’s already a buildpack frontend in the community repo, and it works great. Writing your own frontend is real straightforward.

Honestly after years of stagnation, the most exciting work on container building is now coming out of Docker. Buildkit is amazing, a real hidden gem.

See https://github.com/moby/buildkit

Post reply on HN