5 ms·

Build a Container Image from Scratch

196 points by prakashdanish 2y ago

tmaly 2y ago
Is there a windows version ?
- donno 2y ago
  Windows is is very similar, the differences are two the layer tarballs. The file system appears in a Files sub-directory as there is a Hives sub-directory for containing the Windows Registry. The other difference is there are two extra PAX headers within the tarball, MSWINDOWS.fileattr which is "32" for a regular file, and "16" for a directory and MSWINDOWS.rawsd which is a special encoding of the security descriptor, which you can think of it as the owner, group and permissions associated with the file (which their standard values can be seen from buildkit here: https://github.com/moby/buildkit/blob/22156ab20bcaea1a1466d277dbf1f1386fa23bd9/util/winlayers/differ.go#L194-L204 https://github.com/moby/buildkit/blob/22156ab20bcaea1a1466d2...) I haven't looked into how to handle the Windows Registry aspect as in my exploration I was focused on simply adding a pre-built executable so I didn't need any registry entries created. The other fun gotcha is to ensure the ENV section contain PATH set to c:\\Windows\\System32;c:\\Windows otherwise you would be unlikely to be able to run any Windows executable.
  - stackskipton 2y ago
    Registry is best handled with copy .reg file and CMD reg import blah.reg in Dockerfile
- kritr 2y ago
  Running the container on Windows is probably a lot more complicated because there’s no obvious built in chroot + mount filesystem command (at least from memory). I believe they’re built on silos. I believe containerd itself is probably as low in the container runtime as you’d want to go… See https://github.com/microsoft/hcsshim https://github.com/microsoft/hcsshim for the actual bindings.
- fazeirony 2y ago
  would WSL work? (sorry, not used windows in a hot minute...)
mortar 2y ago
Just learnt about whiteout files from this, thanks! Trying to understand if you purposely included a filename into a layer with the same whiteout prefix “.wh.”, if it would mess with the process that is meant to obfuscate that prefix from subsequent layers.
- m463 2y ago
  I learned about $_ echo abc && echo $_ abc abc except it's used with wget... wget URL && tar -xvf $_ does this work? Shouldn't tar take a filename? hmm... also, it says there is an alpine layer with "FROM scratch"??
  - godelski 2y ago
    $_ is the last argument. Here's a better example to illustrate > echo 'Hello' 'world' 'my' 'name' 'is' 'godelski' Hello world my name is godelski > echo $_ godelski > !:0 !:1 !:2 "I'm" "$_" Hello world I'm godelski The reference manual is here[0] and here's a more helpful list[1] One of my favorites is > git diff some/file/ugh/hierarchy.cpp > git add $_ ## Alternatively, but this is more cumbersome (but more flexible) !!:s^diff^add So what is happening with wget is > wget https://dl-cdn.alpinelinux.org/alpine/v3.18/releases/x86_64/alpine-minirootfs-3.18.4-x86_64.tar.gz && tar -xvf $_ ## Becomes > wget https://dl-cdn.alpinelinux.org/alpine/v3.18/releases/x86_64/alpine-minirootfs-3.18.4-x86_64.tar.gz > tar -xvf https://dl-cdn.alpinelinux.org/alpine/v3.18/releases/x86_64/alpine-minirootfs-3.18.4-x86_64.tar.gz Which you are correct, doesn't work. It should actually be something like this > wget https://dl-cdn.alpinelinux.org/alpine/v3.18/releases/x86_64/alpine-minirootfs-3.18.4-x86_64.tar.gz -O alpine.tar.gz && tar xzf $_ This would work as the last parameter is correct. I also added `z` to the tar and removed `-` because it isn't needed. Note that `v` often makes untaring files MUCH slower [0] https://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html https://www.gnu.org/software/bash/manual/html_node/Bash-Vari... [1] https://www.gnu.org/software/bash/manual/html_node/Variable-Index.html https://www.gnu.org/software/bash/manual/html_node/Variable-...
    - ryencoke 2y ago
godelski 2y ago
I often wonder, why isn't systemd-nspawn[0] used more often? It's self-described as "chroot on steroids". IME it pretty much lives up to that name. Makes it really easy to containerize things and since it integrates well with systemd you basically don't have to learn new things. I totally get these are different tools and I don't think nspawn makes docker or podman useless, but I do find it interesting that it isn't more used, especially in things you're using completely locally. Say, your random self-hosted server thing that isn't escaping your LAN (e.g. Jellyfin or anything like this) [0] https://wiki.archlinux.org/title/Systemd-nspawn https://wiki.archlinux.org/title/Systemd-nspawn
- deleted 2y ago
  [deleted]
- cmeacham98 2y ago
  Because Docker/OCI/etc got the most important part right (or at least much better than the alternatives): distribution. All you need to start running a Docker container is a location and tag (or hash). To update, all you do is bump the tag (or hash). If a little more complicated setup is necessary (environment variables, volumes, ports, etc) - this can all be easily represented in common formats like Docker compose or Kubernetes manifests. How do you start running a system-nspawn container? Well first, you bootstrap an entire OS, then deal with that OS's package manager to install the application. You have to manage updates with the package manager yourself (which likely aren't immutable). There's no easy declarative config - you'll probably end up writing a shell script or using a third party tool like Ansible. There have been many container/chroot concepts in the past. Docker's idea was not novel, but they did building and distribution far better than any alternative when it first released, and it still holds up well today.
  - ranger207 2y ago
    Yeah, this. Docker/container's greatest feature is less the sandboxing than the distribution. The sandboxing is essential to making the distribution work well, but it's a side feature most of the time
deleted 2y ago
[deleted]
jmholla 2y ago
If the author is here, I think there's a typo in this. In section 1.4, you start working from the scratch layer, but the content continues to refer to alpine as the base layer. FROM scratch COPY ./hello /root/ ENTRYPOINT ["./hello"] > Here, our image contains 2 layers. The first layer comes from the base image, the alpine official docker image i.e. the root filesystem with all the standard shell tools that come along with an alpine distribution. Almost every instruction inside a Containerfile generates another layer. So in the Containerfile above, the COPY instruction creates the second layer which includes filesystem changes to the layer before it. The change here is “adding” a new file—the hello binary—to the existing filesystem i.e. the alpine root filesystem.
- psnehanshu 2y ago
  That, and they also added the "time" command in the config with the scratch base image.
- prakashdanish 2y ago
  Thanks for pointing that out, I'm curating a PR with all the suggestion from here, should be fixed soon!
DeathArrow 2y ago
By containers here the author seems to understand Docker containers. But there are other types of containers like Linux/OpenVZ containers, Windows containers etc.
- adminm 2y ago
  Yep. Also containers used in the shipping industry. You might have yet another ype in your fridge. The thing is that because Docker started the craze, the word "container" without further context in the IT world has become to mean docker container.
- prakashdanish 2y ago
  Yes that's what I meant, but while not specifically Docker containers, I did mean Linux containers that are most commonly managed by container engines such as Podman or Docker.

196 points by prakashdanish 2y ago

tmaly 2y ago

Is there a windows version ?

donno 2y ago
Windows is is very similar, the differences are two the layer tarballs. The file system appears in a Files sub-directory as there is a Hives sub-directory for containing the Windows Registry. The other difference is there are two extra PAX headers within the tarball, MSWINDOWS.fileattr which is "32" for a regular file, and "16" for a directory and MSWINDOWS.rawsd which is a special encoding of the security descriptor, which you can think of it as the owner, group and permissions associated with the file (which their standard values can be seen from buildkit here: https://github.com/moby/buildkit/blob/22156ab20bcaea1a1466d277dbf1f1386fa23bd9/util/winlayers/differ.go#L194-L204 https://github.com/moby/buildkit/blob/22156ab20bcaea1a1466d2...) I haven't looked into how to handle the Windows Registry aspect as in my exploration I was focused on simply adding a pre-built executable so I didn't need any registry entries created. The other fun gotcha is to ensure the ENV section contain PATH set to c:\\Windows\\System32;c:\\Windows otherwise you would be unlikely to be able to run any Windows executable.
- stackskipton 2y ago
  Registry is best handled with copy .reg file and CMD reg import blah.reg in Dockerfile
kritr 2y ago
Running the container on Windows is probably a lot more complicated because there’s no obvious built in chroot + mount filesystem command (at least from memory). I believe they’re built on silos. I believe containerd itself is probably as low in the container runtime as you’d want to go… See https://github.com/microsoft/hcsshim https://github.com/microsoft/hcsshim for the actual bindings.
fazeirony 2y ago
would WSL work? (sorry, not used windows in a hot minute...)

mortar 2y ago

Just learnt about whiteout files from this, thanks! Trying to understand if you purposely included a filename into a layer with the same whiteout prefix “.wh.”, if it would mess with the process that is meant to obfuscate that prefix from subsequent layers.

m463 2y ago
I learned about $_ echo abc && echo $_ abc abc except it's used with wget... wget URL && tar -xvf $_ does this work? Shouldn't tar take a filename? hmm... also, it says there is an alpine layer with "FROM scratch"??
- godelski 2y ago
  $_ is the last argument. Here's a better example to illustrate > echo 'Hello' 'world' 'my' 'name' 'is' 'godelski' Hello world my name is godelski > echo $_ godelski > !:0 !:1 !:2 "I'm" "$_" Hello world I'm godelski The reference manual is here[0] and here's a more helpful list[1] One of my favorites is > git diff some/file/ugh/hierarchy.cpp > git add $_ ## Alternatively, but this is more cumbersome (but more flexible) !!:s^diff^add So what is happening with wget is > wget https://dl-cdn.alpinelinux.org/alpine/v3.18/releases/x86_64/alpine-minirootfs-3.18.4-x86_64.tar.gz && tar -xvf $_ ## Becomes > wget https://dl-cdn.alpinelinux.org/alpine/v3.18/releases/x86_64/alpine-minirootfs-3.18.4-x86_64.tar.gz > tar -xvf https://dl-cdn.alpinelinux.org/alpine/v3.18/releases/x86_64/alpine-minirootfs-3.18.4-x86_64.tar.gz Which you are correct, doesn't work. It should actually be something like this > wget https://dl-cdn.alpinelinux.org/alpine/v3.18/releases/x86_64/alpine-minirootfs-3.18.4-x86_64.tar.gz -O alpine.tar.gz && tar xzf $_ This would work as the last parameter is correct. I also added `z` to the tar and removed `-` because it isn't needed. Note that `v` often makes untaring files MUCH slower [0] https://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html https://www.gnu.org/software/bash/manual/html_node/Bash-Vari... [1] https://www.gnu.org/software/bash/manual/html_node/Variable-Index.html https://www.gnu.org/software/bash/manual/html_node/Variable-...
  - ryencoke 2y ago

godelski 2y ago

I often wonder, why isn't systemd-nspawn[0] used more often? It's self-described as "chroot on steroids". IME it pretty much lives up to that name. Makes it really easy to containerize things and since it integrates well with systemd you basically don't have to learn new things. I totally get these are different tools and I don't think nspawn makes docker or podman useless, but I do find it interesting that it isn't more used, especially in things you're using completely locally. Say, your random self-hosted server thing that isn't escaping your LAN (e.g. Jellyfin or anything like this) [0] https://wiki.archlinux.org/title/Systemd-nspawn https://wiki.archlinux.org/title/Systemd-nspawn

deleted 2y ago
[deleted]
cmeacham98 2y ago
Because Docker/OCI/etc got the most important part right (or at least much better than the alternatives): distribution. All you need to start running a Docker container is a location and tag (or hash). To update, all you do is bump the tag (or hash). If a little more complicated setup is necessary (environment variables, volumes, ports, etc) - this can all be easily represented in common formats like Docker compose or Kubernetes manifests. How do you start running a system-nspawn container? Well first, you bootstrap an entire OS, then deal with that OS's package manager to install the application. You have to manage updates with the package manager yourself (which likely aren't immutable). There's no easy declarative config - you'll probably end up writing a shell script or using a third party tool like Ansible. There have been many container/chroot concepts in the past. Docker's idea was not novel, but they did building and distribution far better than any alternative when it first released, and it still holds up well today.
- ranger207 2y ago
  Yeah, this. Docker/container's greatest feature is less the sandboxing than the distribution. The sandboxing is essential to making the distribution work well, but it's a side feature most of the time

deleted 2y ago

[deleted]

jmholla 2y ago

If the author is here, I think there's a typo in this. In section 1.4, you start working from the scratch layer, but the content continues to refer to alpine as the base layer. FROM scratch COPY ./hello /root/ ENTRYPOINT ["./hello"] > Here, our image contains 2 layers. The first layer comes from the base image, the alpine official docker image i.e. the root filesystem with all the standard shell tools that come along with an alpine distribution. Almost every instruction inside a Containerfile generates another layer. So in the Containerfile above, the COPY instruction creates the second layer which includes filesystem changes to the layer before it. The change here is “adding” a new file—the hello binary—to the existing filesystem i.e. the alpine root filesystem.

psnehanshu 2y ago
That, and they also added the "time" command in the config with the scratch base image.
prakashdanish 2y ago
Thanks for pointing that out, I'm curating a PR with all the suggestion from here, should be fixed soon!

DeathArrow 2y ago

By containers here the author seems to understand Docker containers. But there are other types of containers like Linux/OpenVZ containers, Windows containers etc.

adminm 2y ago
Yep. Also containers used in the shipping industry. You might have yet another ype in your fridge. The thing is that because Docker started the craze, the word "container" without further context in the IT world has become to mean docker container.
prakashdanish 2y ago
Yes that's what I meant, but while not specifically Docker containers, I did mean Linux containers that are most commonly managed by container engines such as Podman or Docker.