eksctl
eksctl copied to clipboard
eksctl-io
Create linux packages
Why do you want this feature?
I would like to be able to install eksctl easily on Linux. Currently we have a homebrew package but we should have .deb and .rpm packages as well to cover somew of the main linux distros.
What feature/behavior/change do you want?
I expect to be able to do apt-get install eksctl and it install eksctl and its dependencies (i.e. kubectl, aws-iam-authenticator).
Gorealeaser should be able to help here: https://goreleaser.com/nfpm/ https://github.com/goreleaser/nfpm
For .deb packages, I'm happy to help figure this out. We could set up a PPA for Weaveworks and publish bits like eksctl, fluxctl and potentially more in there. Unfortunately this would require quite a few things to be set up in CI to publish automatically (GPG signing keys, etc.)
Another route would be snaps. They'd be easier to set up (one yaml file, simple Github build/publish integration) and would work on many different Linux distributions. A potential blocker could be access to dot files. It's what I encountered when building eksctl.
As a follow-up, the discussion regarding Snaps moved on to here, and I passed on YAMLs as test-cases for this extension of snaps for both eksctl and fluxctl.
Yes, we're aware of that. It'd be good if we could look into merging https://github.com/weaveworks/eksctl/pull/969 soon and then take over the snap in the store.
#969 is ready to go. Here's what I suggest we do:
- [x] merge #969
- [x] set up shared account at snapcraft.io to maintain the snap there
- [x] (dholbach) talk to snap store team to take over eksctl snap → https://forum.snapcraft.io/t/take-over-maintenance-of-eksctl-snap/15042 → also filed name dispute request
- [ ] test eksctl snap in earnest
- [ ] figure out publication CI steps
- [ ] document how to install the snap in site/content/introduction/02-installation.md
Following up on the last item in the TODO above: our options for publishing (once we take over maintenance of the unmaintained eksctl snap in the store):
- publish manually whenever we please
- publish through CI through a mechanism we can figure out ourselves
- publish using build.snapcraft.io (which would require us to at least temporarily give admin privs of the GH repo to the build service, so it can set up a webhook - not sure if that's acceptable for us: background is https://github.com/canonical-web-and-design/build.snapcraft.io/issues/1191)
Maintenance of the eksctl snap was transferred to us: https://snapcraft.io/eksctl
I pushed the last release to stable. Unfortunately git checkout 0.12.0 && snapcraft produced 0.12.0-rc.0 as version number. Not sure why this is the case.
In any case, I'd love to get feedback on how well the snap works.
Installing on Ubuntu et al (if you have snapd installed) is just a matter of running:
sudo snap install eksctl
If you have eksctl somewhere else in your $PATH, you might want to run which eksctl to figure out which one is being used.
Ah, and I pushed the most recent master to edge:
Track Arch Channel Version Revision
latest amd64 stable 0.12.0-rc.0 3
candidate ^ ^
beta ^ ^
edge 0.12.0-rc.0+ca1a6f73 4
I just disabled the snap in the store. We'll need to figure out #1721 and some other issues first.
I expect to be able to do apt-get install eksctl and it install eksctl
Yes, so much yes.
and its dependencies (i.e. kubectl, aws-iam-authenticator).
But kubectl isn't actually a dependency of eksctl, is it? I wouldn't expect installing eksctl to also install kubectl.
As I understand it. the version of kubectl I need to be installed depends on the version of the cluster I'm interacting with, so I would want these packages completely decoupled.
kubectl, all its versions, are available in Kubernetes' own repo.
See "Ubuntu, Debian or HypriotOS" instructions in the Install and Set Up kubectl documentation.
Closing this given the following comment in a related issue and due to lack of activity: https://github.com/weaveworks/eksctl/issues/3436#issuecomment-800161539
Hi @toabctl, we used to have a snap on snapcraft, but the team decided to stop releasing snaps about a year ago as it was too much work to maintain.
Happy to reopen it if there is more interest!
Okay so yeah this needs to be re-opened, because frankly, AWS' "recommended" method of installing eksctl by downloading a tar and moving the binary into place, is absolutely the worst way to do this.
- It means the package will NEVER be updated, because the environmental package manager is not aware of it.
- It will NEVER be updated because the human user will likely forget that it needs updating.
- Because it never gets updated over time this is likely to result in security issues, just like any other piece of software that never gets update
- This is the least convenient and efficient way to do it, like package managers have plenty of good reasons to exist, this includes convenience and reduced administrative overhead.
I for one prefer that a ppa/repo for debs be established for eksctl, since snaps have their own problems (such as init time), and making them debs means that Debian, Ubuntu and other derivatives (that may not even have snapd or whatever) can just use it.
I am in AWE that this has not become a thing. Original request was Sep 2018, it is now Mar 2022. The need for packages in repos hasn't gone away.
Can we please re-open this and get this sorted already? I mean, I'm sure even the Red Hat enjoyers probably also want rpm versions with their own repos too... for exactly the same reasons... (BTW, I use Ubuntu, not Arch, lol)
Okay so I went to look at the release frequency for this github project and holly balls are releases coming out frequently. That's literally so much more reason for this to be served via a repository instead of a tarball a human manually downloads!
There were several problems with credentials when dealing with the release cycle not in github which is why this didn't go forward in the end.
As for your comment:
Regarding updates:
As with anything installed from not a package, you can add a small script that keeps it updated and run a systemd process in the background and forget about it basically. It's relatively simple to achieve.
method of installing eksctl by downloading a tar and moving the binary into place, is absolutely the worst way to do this.
I would argue that having to run ./configure && make would be a lot worse. ;)
I for one prefer that a ppa/repo for debs be established for eksctl, since snaps have their own problems (such as init time), and making them debs means that Debian, Ubuntu and other derivatives (that may not even have snapd or whatever) can just use it.
I see no reason why not to also add deb packages. That's true. But we will not host it, because it creates a lot of overhead for an already stretched thin team to take care of. But we can publish them as artifacts I believe.
To summarise, this ticket is now about just creating and publish a .deb and potentially an .rpm file.
FWIW I would still like to see a snap (given https://github.com/weaveworks/eksctl/issues/1721#issuecomment-618533261). Would match how I keep other K8s-related tools like kubectl, helm, and gcloud up to date. (Sadly, not aws-cli, which also has a ridiculously outdated snap.)
There were several problems with credentials when dealing with the release cycle not in github which is why this didn't go forward in the end.
As for your comment:
Regarding updates:
As with anything installed from not a package, you can add a small script that keeps it updated and run a systemd process in the background and forget about it basically. It's relatively simple to achieve.
method of installing eksctl by downloading a tar and moving the binary into place, is absolutely the worst way to do this.
I would argue that having to run
./configure && makewould be a lot worse. ;)I for one prefer that a ppa/repo for debs be established for eksctl, since snaps have their own problems (such as init time), and making them debs means that Debian, Ubuntu and other derivatives (that may not even have snapd or whatever) can just use it.
I see no reason why not to also add deb packages. That's true. But we will not host it, because it creates a lot of overhead for an already stretched thin team to take care of. But we can publish them as artifacts I believe.
So you're proposing I write a script to emulate a package manager without any of the GPG key signage, or other good practices found in mature package managers? I'm sorry but that's really not an okay recommendation.
I understand that this adds overhead to the team, but this can be automated, I'm sure. Isn't that what DevOps is about? :^)
Also saying this is better than compiling from source does not detract the value of what is being sought here.
To summarise, this ticket is now about just creating and publish a .deb and potentially an .rpm file.
It has been about that this whole time, as per the original request (not by me) including "Currently we have a homebrew package but we should have .deb and .rpm packages as well to cover somew of the main linux distros"
FWIW I would still like to see a snap (given #1721 (comment)). Would match how I keep other K8s-related tools like
kubectl,helm, andgcloudup to date. (Sadly, notaws-cli, which also has a ridiculously outdated snap.)
I would like to point out that kubectl and awscli can be installed via package managers. That's literally how I do it already. Perhaps consider that method instead?
So you're proposing I write a script to emulate a package manager without any of the GPG key signage, or other good practices found in mature package managers? I'm sorry but that's really not an okay recommendation.
How does it help with updates to have a downloadable deb package? You still would have to update that by hand.
I understand that this adds overhead to the team, but this can be automated, I'm sure. Isn't that what DevOps is about? :^)
We accept community contributions. :^)
It has been about that this whole time, as per the original request
No it has not:
What feature/behavior/change do you want? I expect to be able to do apt-get install eksctl and it install eksctl and its dependencies (i.e. kubectl, aws-iam-authenticator).
I would like to point out that kubectl and awscli can be installed via package managers. That's literally how I do it already. Perhaps consider that method instead?
Done.
awscli can be installed via package managers
At least on Ubuntu, yes but an obsolete 1.x version, and https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html does not suggest a package. Frankly using a Docker wrapper script as in https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-docker.html#cliv2-docker-share-files feels like a more attractive option, at least on Linux where Docker containers require no VM.
Closing this as this is not our immediate priority and lack of interest from the community, if this issue gets a lot of 👍🏻 s then we will consider making this our priority. Meanwhile, we are happy to accept contributions from the community 🎉
Still desired!
Sadly, we just simply don't have the capacity to do this on our own. Help would be much appreciated. :)
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}