Answers: <p>Podman and Buildah are userspace tools. They don't require root access. They can also build <code>oci</code> and <code>docker</code> images,</p>
  <blockquote>
  <p>Recognized formats include oci (OCI image-spec  v1.0,  the  default)  and  docker (version 2, using schema format 2 for the manifest).</p>
  </blockquote>
  <p>Note while Buildah can build from a dockerfile, you really shouldn't ever create dockerfiles. The normal method of operation with buildah involves creating a shell script, which provides you amongst other things a path into the off-line mount point, shell expansion, and conditionals, and the ability to run things in the container before committing (great for initialization).</p>
  <p>Here is a quick example without dockerfile, <code>build_image.sh</code></p>
  <pre class="lang-shell prettyprint-override"><code>#!/bin/bash
  
  ctr=$(buildah from alpine:3)
  mnt=$(buildah mount &quot;$ctr&quot;)
  
  mkdir &quot;$mnt/rootleveldir&quot;
  cp ./localfile &quot;$mnt/rootleveldir&quot;
  
  buildah run -v &quot;$PWD:$PWD&quot; -- sh $PWD/init.sh
  
  buildah config --entrypoint &quot;/rootleveldir&quot; --cmd &quot;run.sh&quot;;
  
  buildah commit                 \
    --author &quot;Evan Carroll&quot;      \
    --rm                         \
    &quot;$ctr&quot; &quot;localhost:myimage&quot;;
  </code></pre>
  <p>Create the image without root with <code>buildah unshare ./build_image.sh</code></p>
  <p>Podman can commit any online container to an image, and buildah can commit any offline container to an image.</p>
  
Answers: CC BY-SA 4.0
Answers: 2022-06-15T22:20:51.550Z
Answers: Thanks for this info. Even though they are user space tools, they require the system they run on to be set up in a specific way by an administrator. Hence a user can't build or run podman/buildah on a system which is not set up for them to work already.
Answers: Plazgoth
Answers: CC BY-SA 4.0
Answers: 2022-06-15T22:28:41.753Z
Answers: @Plazgoth I'm not sure what you mean. You can use mount without unshare, and unshare puts you in a namespace that has to be created (which requires root). But the rest afaik will run just fine with builldah https://opensource.com/article/19/3/tips-tricks-rootless-buildah
Answers: Evan Carroll
Answers: CC BY-SA 4.0
Answers: 2022-06-15T22:28:57.330Z
Answers: @Plazgoth perhaps try it, get an error, ask with that error.
Answers: Evan Carroll
Answers: CC BY-SA 4.0
Answers: 2022-06-15T22:54:40.663Z
Answers: I am not sure what you are suggesting I try. To build a buildah executable from source?
Answers: Plazgoth
Answers: CC BY-SA 4.0
Answers: 2022-06-15T23:01:13.430Z
Answers: @Plazgoth Sure. that's one method. Or use your package manager to download it. Then extract it from the package and put it in `~/.locall/bin` and add that to your path.
Answers: Evan Carroll
Answers: CC BY-SA 4.0
Answers: 2022-06-17T22:08:23.713Z
Answers: I did try it and here is the error:
  $ buildah --version && buildah help
  
  buildah version 1.11.6 (image-spec 1.0.1-dev, runtime-spec 1.0.1-dev)
  Error during unshare(CLONE_NEWUSER): Invalid argument
  User namespaces are not enabled in /proc/sys/user/max_user_namespaces.
  ERRO error parsing PID "": strconv.Atoi: parsing "": invalid syntax
  ERRO (unable to determine exit status)
Answers: Plazgoth
Answers: CC BY-SA 4.0
Answers: 2022-06-17T23:37:08.470Z
Answers: @Plazgoth Right, you need user-namespaces enabled in the kernel. That has nothing to do with buildah though, you can't do _anything_ with rootless containers without user namespaces enabled. It's a kernel thing. https://unix.stackexchange.com/a/303214/3285
Answers: Evan Carroll
Answers: CC BY-SA 4.0
Answers: 2022-05-25T17:45:08.683Z
Answers: 2022-05-25T17:53:32.940Z
Answers: 2022-05-25T17:53:32.940Z
Answers: Evan Carroll
Answers: <p>Yes, it's possible. For example, in Java you can use <a href="https://github.com/GoogleContainerTools/jib" rel="nofollow noreferrer">Jib</a> to build an image without docker. Now whether you <em>should</em> do this is a different question :)</p>
  
Answers: CC BY-SA 4.0
Answers: 2024-07-15T20:44:59.217Z
Answers: 2024-07-15T20:44:59.217Z
Answers: Almenon
Answers: <p>An image is based on the <a href="https://github.com/opencontainers/image-spec/blob/main/spec.md" rel="nofollow noreferrer">OCI image-spec</a> which consists of filesystem layers packaged as tar files, a config json, and a manifest. All of these are referenced with a content addressable digest. If you can create these tar and json files, then you can create an image without a runtime.</p>
  <p>There are various tools that do this for specific cases. I think most are shipped as containers and designed to run in CI pipelines, but you can probably get standalone binaries. However, I don't think any of these work with a Dockerfile, so if you need something that supports that syntax, you'll need a container runtime. There are rootless runtimes, but they typically have prerequisites that need to be performed on the host by root in advance, and there's a performance hit from using them.</p>
  
Answers: CC BY-SA 4.0
Answers: 2022-04-22T19:54:33.307Z
Answers: As far as I know, [`buildah bud`](https://developers.redhat.com/blog/2021/01/11/getting-started-with-buildah) is able to work with dockerfiles without a full container runtime environment.
Answers: Turing85
Answers: CC BY-SA 4.0
Answers: 2022-04-22T20:06:09.450Z
Answers: @Turing85 for the `RUN` steps, I'm pretty sure you'll need a runtime. Running it outside of a container wouldn't be very reproducible (but then they use all kinds of host resources with that tool). What you can do is have that tool be rootless, and I think RHEL has been baking in the prereqs for that, along with other newer Linux distros.
Answers: BMitch
Answers: CC BY-SA 4.0
Answers: 2022-06-15T22:25:21.667Z
Answers: I did find an interesting writeup based on ideas from your answer: https://developers.redhat.com/blog/2019/08/14/best-practices-for-running-buildah-in-a-container#
Answers: Plazgoth
Answers: CC BY-SA 4.0
Answers: 2022-04-22T17:01:53.733Z
Answers: 2022-04-22T17:01:53.733Z
Answers: BMitch
Body: <p>Is it possible to build a container image as a simple user account on a system which does not have docker or podman installed? In other words, is there a user-space tool/application which can build an image that could run on a different system which supports OCI containers, such as AKS, etc.</p>
  
Comments: CC BY-SA 4.0
Comments: 2022-05-28T17:17:00.250Z
Comments: Do you build a docker from your Dockerfile in a machine without docker?
Comments: JRichardsz
Tags: <docker><kubernetes><containers>
Title: Creating container image without docker
UserDisplayName: Plazgoth
ThreadText: # Creating container image without docker
  
  (Asked by: username_0 on 2022-04-22)
  
  Is it possible to build a container image as a simple user account on a system which does not have docker or podman installed? In other words, is there a user-space tool/application which can build an image that could run on a different system which supports OCI containers, such as AKS, etc.
  
  **Tags:** docker, kubernetes, containers
  
  > **Comments:**
  > **username_1**: Do you build a docker from your Dockerfile in a machine without docker?  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_4 on 2022-04-22. Score: 3 | Accepted answer
  
  An image is based on the [OCI image-spec](https://github.com/opencontainers/image-spec/blob/main/spec.md) which consists of filesystem layers packaged as tar files, a config json, and a manifest. All of these are referenced with a content addressable digest. If you can create these tar and json files, then you can create an image without a runtime.
  
  There are various tools that do this for specific cases. I think most are shipped as containers and designed to run in CI pipelines, but you can probably get standalone binaries. However, I don't think any of these work with a Dockerfile, so if you need something that supports that syntax, you'll need a container runtime. There are rootless runtimes, but they typically have prerequisites that need to be performed on the host by root in advance, and there's a performance hit from using them.
  
  > **Comments:**
  > **username_5**: As far as I know, [`buildah bud`](https://developers.redhat.com/blog/2021/01/11/getting-started-with-buildah) is able to work with dockerfiles without a full container runtime environment.  
  > **username_4**: @username_5 for the `RUN` steps, I'm pretty sure you'll need a runtime. Running it outside of a container wouldn't be very reproducible (but then they use all kinds of host resources with that tool). What you can do is have that tool be rootless, and I think RHEL has been baking in the prereqs for that, along with other newer Linux distros.  
  > **username_0**: I did find an interesting writeup based on ideas from your answer: https://developers.redhat.com/blog/2019/08/14/best-practices-for-running-buildah-in-a-container#  
  
  ---
  
  ### Answer by username_2 on 2022-05-25. Score: 1
  
  Podman and Buildah are userspace tools. They don't require root access. They can also build `oci` and `docker` images,
  
  > Recognized formats include oci (OCI image-spec v1.0, the default) and docker (version 2, using schema format 2 for the manifest).
  
  Note while Buildah can build from a dockerfile, you really shouldn't ever create dockerfiles. The normal method of operation with buildah involves creating a shell script, which provides you amongst other things a path into the off-line mount point, shell expansion, and conditionals, and the ability to run things in the container before committing (great for initialization).
  
  Here is a quick example without dockerfile, `build_image.sh`
  
  ```shell
  #!/bin/bash
  
  ctr=$(buildah from alpine:3)
  mnt=$(buildah mount "$ctr")
  
  mkdir "$mnt/rootleveldir"
  cp ./localfile "$mnt/rootleveldir"
  
  buildah run -v "$PWD:$PWD" -- sh $PWD/init.sh
  
  buildah config --entrypoint "/rootleveldir" --cmd "run.sh";
  
  buildah commit                 \
    --author "username_2 username_2"      \
    --rm                         \
    "$ctr" "localhost:myimage";
  
  ```
  
  Create the image without root with `buildah unshare ./build_image.sh`
  
  Podman can commit any online container to an image, and buildah can commit any offline container to an image.
  
  > **Comments:**
  > **username_0**: Thanks for this info. Even though they are user space tools, they require the system they run on to be set up in a specific way by an administrator. Hence a user can't build or run podman/buildah on a system which is not set up for them to work already.  
  > **username_2**: @username_0 I'm not sure what you mean. You can use mount without unshare, and unshare puts you in a namespace that has to be created (which requires root). But the rest afaik will run just fine with builldah https://opensource.com/article/19/3/tips-tricks-rootless-buildah  
  > **username_2**: @username_0 perhaps try it, get an error, ask with that error.  
  > **username_0**: I am not sure what you are suggesting I try. To build a buildah executable from source?  
  > **username_2**: @username_0 Sure. that's one method. Or use your package manager to download it. Then extract it from the package and put it in `~/.locall/bin` and add that to your path.  
  > **username_0**: I did try it and here is the error: $ buildah --version && buildah help  buildah version 1.11.6 (image-spec 1.0.1-dev, runtime-spec 1.0.1-dev) Error during unshare(CLONE_NEWUSER): Invalid argument User namespaces are not enabled in /proc/sys/user/max_user_namespaces. ERRO error parsing PID "": strconv.Atoi: parsing "": invalid syntax ERRO (unable to determine exit status)  
  > **username_2**: @username_0 Right, you need user-namespaces enabled in the kernel. That has nothing to do with buildah though, you can't do _anything_ with rootless containers without user namespaces enabled. It's a kernel thing. https://unix.stackexchange.com/a/303214/3285  
  
  ---
  
  ### Answer by username_3 on 2024-07-15. Score: 0
  
  Yes, it's possible. For example, in Java you can use [Jib](https://github.com/GoogleContainerTools/jib) to build an image without docker. Now whether you *should* do this is a different question :)
  
  
  ---
  
  