-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Installing podman from a tarball #8788
Comments
Maybe Github actions could be used for this? I made use of the PREFIX argument ( A tip: How to use Systemd services with a home-directory Podman installationIf you want use Podman that was installed into your home directory (e.g. ~/podman/bin/podman) in a systemd service, you need to use an absolute path in the ExecStart.
(It took some time before I realized that) |
If you like the Nix binaries, there are build instructions here: They are similar to the "static" ones built for cri-o, similarly: If I understand correctly, all that is "missing" is to upload these binaries to the cloud storage, on each release ? Possibly it would need some kind of similar "bundle" script, in order to include conmon/crun and other dependencies... |
@eriksjolund : your script looks very specific to CentOS 7/8 ? minikube currently builds podman from source (github).
Eventually buildroot will figure out how to support go modules, but right now it doesn't have a good way of storing distfiles... Hopefully it will be sorted out before the Buildroot 2021.02 release, or maybe we will change the minikube OS before then. Also minikube only uses sudo podman, for cri-o/kubernetes. That means that it doesn't need any of the rootless support. |
@afbjorklund : Yes, I forgot to mention that. |
The nix build sure downloads a lot of files... curl -L https://nixos.org/nix/install | sh
nix build -f nix/ And then it failed, when building another go. `builder for '/nix/store/bg4hnzq2mvkl39a31np06rx7pf5sp3jc-go-1.15.3.drv' failed with exit code 1
|
Also, since CentOS already includes podman - you are now likely to have some version conflicts with the system ?
Similar to when you mix and match the OpenSUSE Build System binaries for Ubuntu, with the system packages...
|
I tried to upgrade nix, but just ended up with different build errors (this time, "fontforge" failed). We normally use the OBS* for installing podman and cri-o, so will probably just continue with that... * https://build.opensuse.org/project/show/devel:kubic:libcontainers:stable Previously had to build our own packages, but now back at latest/greatest |
@bharath-123 : this seems to have been talked about before, in issue But it's not clear what the outcome was, the download only has podman-remote ? There is #6402 and the nix "derivation", but I'm not sure about official binaries... For docker there is a .tgz with all required files (including containerd and runc) |
@eriksjolund Thanks for your suggestion! But that seems pretty complicated to do :/ My use-case is to be set it up a stable version of podman in kubernetes clusters with automation. Would like to avoid git hooks etc in my code :/. @afbjorklund thanks for your research here. Really appreciate it. Nix is an option but I would definitely prefer a bundled binary like what crio is doing. I am currently adding crio support for kOps. A bundled binary really makes installing easy as all we would need to do is to extract the tar and move files to /usr/bin or any other system. It would be great if podman too has a solution like this too. Would make setting up podman really easy for cluster setup tools. Yup have seen that only podman-remote in the binary, not sure how that would be useful without a full blown setup of podman infrastructure. I would like to know if it would be possible for podman to support releasing bundled binaries like how crio does with every release. |
Unless I am missing something, crio uses Nix in order to do the static builds ? Podmanstatic:
@nix build -f nix/
mkdir -p ./bin
cp -rfp ./result/bin/* ./bin/
CRI-Obuild-static:
$(CONTAINER_RUNTIME) run --rm --privileged -ti -v /:/mnt \
nixos/nix cp -rfT /nix /mnt/nix
$(CONTAINER_RUNTIME) run --rm --privileged -ti -v /nix:/nix -v ${PWD}:${PWD} -w ${PWD} \
nixos/nix nix --print-build-logs --option cores 8 --option max-jobs 8 build --file nix/
mkdir -p bin
cp -r result/bin bin/static
But I have never used the static binaries, just the regular (deb/rpm) packages. Not sure that I would set up clusters, without using proper package management ? It is possible, and I have done it before - but I am not sure that I would do it again...
The missing piece (from crio) here are the "contrib/bundle" scripts, for podman. What they do is copy the configuration, and the binaries from those other projects: You need to add stuff like conmon/crun, and fuse-overlayfs/slirp4netns (for rootless)... If you want details, you can look at: https://podman.io/getting-started/installation#building-from-scratch Many of these projects in podman are the same as in crio, at least for sudo podman. |
When looking at https://kops.sigs.k8s.io/operations/images/ it seems that all supported kops distributions use packages. So it would probably be much easier to use the Kubic packages for cri-o/podman, than to try to use these Nix packages. Do you have some links/details, to your kops addition (for cri-o support) ? https://kops.sigs.k8s.io/cluster_spec/#containerruntime
For minikube we still build our own packages from source, but consider* going over to a supported Linux distribution... We could of course also install podman and crio from binaries, like we currently are doing for docker and containerd. * See kubernetes/minikube#9992 Packaging is boring and takes time |
A friendly reminder that this issue had no activity for 30 days. |
The magic command seems to be: Then it will say why the "make static" actually failed (the hidden @
Due to NixOS/nix#3245 $ nix build -f nix/ /nix/store/gr5g83iagi39nymy8pm7m6xji6c4mdvf-go-1.15.2.drv --option sandbox false
[1 built]
$ nix build -f nix/
warning: dumping very large path (> 256 MiB); this may run out of memory
[1 built, 0.0 MiB DL] |
With that workaround, it was possible to build both releases static again:
The client is built more traditionally, with
But it still needs a static Those can be found in their own external projects, and built separately. |
can we close this issue? |
There are still only static binaries available for podman-remote, not podman: https://github.com/containers/podman/releases/tag/v2.1.1 https://github.com/containers/podman/releases/tag/v2.2.1 Apparently there are no binaries done for RC, so unclear if it is fixed or not ? i.e. if there was a v3.0.0 today, would it include a podman binary ? Note that |
The static build seems to be failing in CI:
But worked in https://cirrus-ci.com/task/4654061322502144 |
My apologies. My gmail account storage had filled up and I did not receive these notifications. We have found a decent workaround installing podman for our use case. But it would be really useful if podman had static binaries available so that we can easily script server bootstrap programs with podman. Podman is useful as it is relatively agnostic to the container runtime. We can close this issue for now. @afbjorklund Please do re-open the issue if you want to keep the discuss going on. |
Same problem with 3.0.0 (RC3)
Same workaround works, though.
|
I uploaded the static binaries here:
EDIT: Update to 3.0.1, since 3.0.0 release was broken |
/kind feature
As far as i can see, the current way of installing podman is very OS specific. This can make it a bit hard to automate installations for softwares which setup kubernetes clusters like kOps, minikube etc...
Cri-o has recently started pushing releases to https://console.cloud.google.com/storage/browser/k8s-conform-cri-o/artifacts;tab=objects?prefix=crio-v&forceOnObjectsSortingFiltering=false . These are pretty easy to use to setup a working crio setup.
Can we do something similar for podman? If not, is there any specific reason or so?
The text was updated successfully, but these errors were encountered: