k3s as RPMs #5618
Comments
|
Okay I want to provide a tldr as a question: What are the requirements for you that k3s can be built in the OBS as an RPM? It is not my intention to complicate things with this request but to make it easier. For me installing an RPM is the easiest way to manage the software I have on my system. I understand that this is not the opinion of everyone but I would like to see it possible that I can go my way and others can go theirs. |
|
Okay I am running into build trouble while building k3s but so far the changes I have come up with are rather minimal... diff --git a/Makefile b/Makefile
index d18f7c1884..c1682be0ea 100644
--- a/Makefile
+++ b/Makefile
@@ -7,8 +7,10 @@ TARGETS := $(shell ls scripts | grep -v \\.sh)
@./.dapper.tmp -v
@mv .dapper.tmp .dapper
+ifndef SKIP_DAPPER
$(TARGETS): .dapper
./.dapper $@
+endif
.PHONY: deps
deps:
@@ -32,3 +34,7 @@ binary-size-check:
.PHONY: image-scan
image-scan:
scripts/image_scan.sh $(IMAGE)
+
+.PHONY: source-tarball
+source-tarball: deps
+ ./scripts/download
diff --git a/scripts/build b/scripts/build
index d8c27c1400..7d5b4138d2 100755
--- a/scripts/build
+++ b/scripts/build
@@ -97,17 +97,22 @@ cleanup() {
exit ${exit_status}
}
-INSTALLBIN=$(pwd)/bin
-if [ ! -x ${INSTALLBIN}/cni ]; then
-(
- echo Building cni
- TMPDIR=$(mktemp -d)
- trap cleanup EXIT
- WORKDIR=$TMPDIR/src/github.com/containernetworking/plugins
- git clone -b $VERSION_CNIPLUGINS https://github.com/rancher/plugins.git $WORKDIR
- cd $WORKDIR
- GO111MODULE=off GOPATH=$TMPDIR CGO_ENABLED=0 "${GO}" build -tags "$TAGS" -ldflags "$VERSIONFLAGS $LDFLAGS $STATIC" -o $INSTALLBIN/cni
-)
+if [ -z "$SKIP_CNI" ]; then
+ INSTALLBIN=$(pwd)/bin
+ if [ ! -x ${INSTALLBIN}/cni ]; then
+ (
+ echo Building cni
+ TMPDIR=$(mktemp -d)
+ trap cleanup EXIT
+ WORKDIR=$TMPDIR/src/github.com/containernetworking/plugins
+ git clone -b $VERSION_CNIPLUGINS https://github.com/rancher/plugins.git $WORKDIR
+ cd $WORKDIR
+ GO111MODULE=off GOPATH=$TMPDIR CGO_ENABLED=0 "${GO}" build -tags "$TAGS" -ldflags "$VERSIONFLAGS $LDFLAGS $STATIC" -o $INSTALLBIN/cni
+ )
+ fi
+else
+ # TODO: Use pre-built binary if available
+ echo "cni: Using previusly built binary if available"
fi
echo Building k3s
diff --git a/scripts/package b/scripts/package
index 51b8f417bb..ca2123657e 100755
--- a/scripts/package
+++ b/scripts/package
@@ -8,7 +8,9 @@ if [ ! -e ../bin/containerd ]; then
fi
./package-cli
-./package-image
+if [ -z "$SKIP_IMAGE" ]; then
+ ./package-image
+fi
if [ -z "$SKIP_AIRGAP" ]; then
./package-airgap
fi |
|
Okay I tried digging further into the build failure but I don't find a clue here to continue sadly. Help would be much appreciated: |
|
Okay the upgrade to go 1.17 solved my issue. It seems the |
|
I was successful 🥳 A lot can be improved by me optimizing the specfile and ripping the build in multiple subpackages so eventually one can build with a |
|
@brandond What would be your wishes in terms for my refactoring of the k3s build scripts? I have multiple ideas and options. The minimal intrusive changes I already posted above but for a better compatibility I would love to do more. I have much more ideas for cleaning up the scripts folder. I would love to upstream those ideas and even maintain the rpm for you in openSUSE. The only thing I would need is that we work together in terms of what you need so I can find the middle ground that suits both of us. |
|
@SchoolGuy do you have a git branch that allows one to build [ pre-release and unofficial ( for now)] k3s RPMS right now? |
|
@TheBigBear I have something locally. I will clean it up and then provide a branch plus PR. Will take me over the weekend probably. |
|
@TheBigBear I have created WIP PR #5793, I will try to take time and refine it during the weekend. |
|
While we're happy for the k3s community to support/maintain k3s as RPM's, there is currently not any plans for the k3s team to build on OBS as an upstream. |
|
@cwayne18 Yes I am aware and accept that. However it would be nice of your buildscripts to make it easier and allow it. I have a WIP PR open where I am currently refactoring them so it is easier to do that. |
|
@cwayne18 I would love for the k3s team to reconsider their position on not providing official RPM/DEB packages. If I can share my experience: Installing Kubernetes in enterprise environments is often a horrendous experience with a multitude of random shell scripts, container images, systemd units, CNI plugins, etc all required. This is especially bad in air-gapped environments where you must bring all these things together on some internally hosted infra. In my opinion, k3s is uniquely placed to address these challenges because it is already delivered as a single binary. The installation process is really lacking, however, because it relies on running a shell script that brings in lots of artifacts from across the internet and does not play nicely with the native package managers that exist on RHEL and Debian systems. k3s would be a no-brainer in enterprise environments if the team provided official RPM and Deb repos that allowed organisations and administrators to simply I would be happy to provide effort to enable this. I think it would be the best way to deploy and maintain k8s in these kinds of environments. |
|
@benridley My PR is doing 90% of the work for this. Feel free to test it. I am not able to get SELinux to work atm because either I need to adjust the SELinux policy to take the host binaries or I need to link the userspace of whatever OS I am building on atm. Both things are the famous 10% that take 80% of the time. If you don't care about SELinux my PR is working wonderfully according to my testing. |
|
is anyone still working or interested in this? |
|
I am. However I am blocked by the k3s maintainers to actually get this in. Edit: My RPM in the OBS is not compatible with selinux due to the missing copy of the userspace. However without selinux the RPM that is depending on my PR is fully functional. |
|
I am also interested in this. Utilizing rpm for this purpose just makes plain sense in my corporate environment. Not only does it help with air-gapped installations, it also provides an audit trail via dnf and rpmdb that can be queried by third party security tools etc. |
|
I would also be interested in this. |
|
As soon as I have a green light from the k3s team I will rebase my PR and rebuild the RPM that is in my home project to show that the changes I made are working as intended. I am willing to commit to packaging different release series in OBS for the community in a dedicated OBS project if the k3s team is interested. I am not able to commit to fixing bugs outside of the packaging and I have no intention to change the current workflow that is used in the CI. My patchset would be able to serve both the existing CI and the RPM packaging in openSUSE. |
|
Any updates ? |
|
My PR was closed without a lot of reasoning. The method I choose still works but the maintenance effort is only possible when upstream accepts my contribution. As such this ticket is impossible to achieve without a change of heart by the Rancher team. |
|
Well the existence of RKE2 is nice, having an rpm version of k3s would be absolutely amazing. Well I could implement the work that SchoolGuy did, I would rather have an RPM from the vendor, Rancher. |
|
This repository uses a bot to automatically label issues which have not had any activity (commit/comment/label) for 45 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the bot can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the bot will automatically close the issue in 14 days. Thank you for your contributions. |
|
This is still relevant... |
|
Very much still relevant |
|
This is still relevant. |
|
This repository uses a bot to automatically label issues which have not had any activity (commit/comment/label) for 45 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the bot can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the bot will automatically close the issue in 14 days. Thank you for your contributions. |
|
Still an issue |
|
This is still a relevant issue, even after two years. I really wish the maintainers would reconsider their position. |
|
Ping |
Is your feature request related to a problem? Please describe.
At the moment is is not possible to build k3s as an RPM or DEB package. This means I have to use the curl installer to install k3s on my host system. For me this represents an inconvenience because I would like to manage my system(s) via RPM/DEB packages.
Describe the solution you'd like
A build process which would build k3s only from sources checked in before build time. This would enable any Linux distribution to ship k3s in their repositories which should increase the visibility in a great manner. Specific build chains like dapper should not be involved in that process.
Describe alternatives you've considered
I have tried my best to understand how the current build system works and it is not even possible to exchange docker with podman without further bash reconfiguration (symlinks etc.). I have tried to understand the necessity of this - imho - inflexible buildchain and I lack the understanding of the decision sadly. I have tried to research the reasons but I was not successful.
Having a consistent environment for building can be achieved in many ways, I don't see a reason why this has to be achieved with dapper and continuos internet access.
Additional context
You said you'd disable this "for now" and reevaluate this later in #2440. I hope that this reevaluation can be done now. Obviously #1535 would reopen which I would also take care of then.
I am willing to invest my time to maintain this solution in the long term if we can find an agreement on how it should look like according to my desired solution.
Having RPMs and DEBs is not that hard if we consider the following:
git clone ...like done here is not required.iptableswhich are currently a part of the k3s-root repository one can easily again just branch the required version from the distribution of choice like the first bullet point already describes.The effort of doing this should be relatively small since the packaging of all the vendored dependencies is already done, they just need to be taken at the desired point in time. If architected well this doesn't even mean dapper is discontinued but in the end it would be just one options/the preferred option to build k3s.
For me the strongest point for such a solution is that the trust in k3s should be much higher when it comes from the vendor of your OS instead of a third party. Because normally packages are maintained by your OS vendor it is easy to trust them. If I execute a script of a third party I normally would need to establish trust to such a party first.
Additionally if I have an RPM/DEB I have a defined version which is installed. This means I know that a specific version will install a set of files on my system to previously known locations. When I install k3s via the current curl method I don't know what, where and how k3s will install itself on my system.
Lastly if an RPM would be available, one could take advantage of things like the SUSE Manager/Uyuni Content lifecycle management which enables automated staging of the k3s RPMs. This means a company can have an automated rollout for their k3s package with the tools already present in an environment, instead of a custom tailored solution.
Example: One could have a staging cluster where a new k3s package (with a bugfix or new version) is deployed to. If that is successful the package would be promoted to the next environment where the likelihood of that failing is much less then if I would install this directly in an environment.
Backporting
The text was updated successfully, but these errors were encountered: