Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality. Learn more →
Top 23 Go Container Projects
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
kruise
Automated management of large-scale applications on Kubernetes (incubating project under CNCF)
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
devspace
DevSpace - The Fastest Developer Tool for Kubernetes ⚡ Automate your deployment workflow with DevSpace and develop software directly inside Kubernetes.
-
-
-
-
singularity
Singularity has been renamed to Apptainer as part of us moving the project to the Linux Foundation. This repo has been persisted as a snapshot right before the changes.
-
kube-fledged
A kubernetes operator for creating and managing a cache of container images directly on the cluster worker nodes, so application pods start almost instantly
-
wg-access-server
An all-in-one WireGuard VPN solution with a web ui for connecting devices (by freifunkMUC)
-
container
A lightweight yet powerful IoC dependency injection container for the Go programming language (by golobby)
-
connaisseur
An admission controller that integrates Container Image Signature Verification into a Kubernetes cluster
-
-
-
Eru
Eru, a simple, stateless, flexible, production-ready orchestrator designed to easily integrate into existing workflows. Can run any virtualization things in long or short time. (by projecteru2)
-
terrier
Terrier is a Image and Container analysis tool that can be used to scan Images and Containers to identify and verify the presence of specific files according to their hashes.
-
hiboot
hiboot is a high performance web and cli application framework with dependency injection support
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
cat << EOF wget \ https://github.com/goharbor/harbor/releases/download/v2.9.4/\ harbor-offline-installer-v2.9.4.tgz EOF
Apko leverages the APK package format from Alpine and draws inspiration from ko, a fast container image builder for Go applications.
I wish we would rather get rid of Dockerfile in favor of something like buildah does:
https://github.com/containers/buildah/blob/main/examples/lig...
Since Dockerfile is a rather limited and (IMHO) poorly executed re-implementation of a shell script, why not rather use shell directly? Not even bash with coreutils is necessary: even posix sh with busybox can do far more than Dockerfile, and you can use something else (like Python) and take it very far indeed.
https://github.com/uber/kraken?tab=readme-ov-file#comparison...
"Kraken was initially built with a BitTorrent driver, however, we ended up implementing our P2P driver based on BitTorrent protocol to allow for tighter integration with storage solutions and more control over performance optimizations.
Kraken's problem space is slightly different than what BitTorrent was designed for. Kraken's goal is to reduce global max download time and communication overhead in a stable environment, while BitTorrent was designed for an unpredictable and adversarial environment, so it needs to preserve more copies of scarce data and defend against malicious or bad behaving peers.
Despite the differences, we re-examine Kraken's protocol from time to time, and if it's feasible, we hope to make it compatible with BitTorrent again."
Project mention: ⚡⚡ Level Up Your Cloud Experience with These 7 Open Source Projects 🌩️ | /r/Cloud | 2023-12-07Knative
We use https://github.com/uber-go/automaxprocs after we joyfully discovered that Go assumed we had the entire cluster's cpu count on any particular pod. Made for some very strange performance characteristics in scheduling goroutines.
Project mention: A morning with the Rabbit R1: a fun, funky, unfinished AI gadget | news.ycombinator.com | 2024-04-24It does show how incompetent the attacker was, I report below what Retr0id wrote in the issue:
"tl;dr: The "leak" seems real, but doesn't prove any of the claims made in the readme.
This statement from Peiyuan Liao, the rabbit CTO, is consistent with what I'm seeing here: https://twitter.com/liaopeiyuan/status/ 1782922595199033662
So the "leak" is a bit of a nothingburger, containing partial code for the relatively boring process of letting users authenticate with online services through a sandboxed browser session, from which auth tokens etc. can be extracted. You can't infer anything about how LAM does or doesn't work from this.
They likely used "kiosk escape" tricks to get code exec within the box that runs the browser. Assuming their sandboxing is all set up correctly, this isn't particularly concerning, but it does expose the code that runs within the sandbox for analysis. That's what we appear to have here.
The attacker left behind a file named cdk.log, which is an artifact of https://github.com/cdk-team/CDK/, a container pentesting tool. They were clearly trying to escape the sandbox and pivot to somewhere more interesting, but I don't think they managed it. I think "part 2" is a bluff, this is all they have (feel free to prove me wrong, lol).
But that doesn't mean there's nothing here. Lets look at what we do have.
The most interesting detail to me is a package name list in repo/ typescript/common/base-tsconfig.json
[...]
The only code actually present is for q-web-minion-
What follows is my speculation based on the names alone:
"q" seems like a codename for the rabbit device (so q-hole rabbit hole). Q might stand for "quantum".
The problem with trying to log into and interface with consumer-facing services from 'the cloud" is that you'll get IP rate limited, blocked as a bot, etc. It would make sense to proxy traffic back out through the user's device, and that's what I'd hope q-proxy is about. The big downside with this is that it ~doubles latency and halves available bandwidth, magnifying any deficiencies of a flaky 4G connection. This is perhaps partly why their doordash demo chugged so hard. (protip to the team; use a caching proxy, with SSL, MitM. Detect CDN URLs and don't proxy those.)
This is a total stab in the dark but my guess is that bunny-host is where the LAM action happens, and bunny-builder is for LAM training.
cm-quantum-peripheral-common might be the wrist-mounted device teased in the launch event.
Addendum:
It's also possible there were some juicy credentials accessible within the container. But if there were, they aren't in this leak. In particular, it looks like they're using GCP "service account keys' (/credentials/ cm-gcp-service-account-quantum-workload/gcp-service-account- quantum-workload.json), which according to google's docs "create a security risk and are not recommended. Unlike the other credential file types, compromised service account keys can be used by a bad actor without any additional information".
There isn't enough information here (and/or my analysis isn't deep enough - "cloud" is not my forte) to determine if that'll cause any issues in practice, but if there really is a "part 2" leak, I'd guess this is how they got it."
I OCR two screenshots that I did so there could be errors.
I also explored another module, go-containerregistry, in order to build images without root privileges. The approach is completely different, and we can manipulate each component of the container image separately. This can present an advantage, if you're looking for a way to fine tune things.
Project mention: Rootless Docker in a Multi-User Environment – It's All About Context | news.ycombinator.com | 2024-05-26I agree to a certain level. However, it's hard to ensure dependencies to work in the right way without isolation. These two support tickets are a showcase of the essence of the problem: "Same container, different results" [1] and "python3 script fails in singularity container on one machine, but works in same container on another" [2]. In my experience with Singularity, there were many issues like these.
I am not sure why they had to call it a "containerization" solution. It gets a bit philosophical, but IMO containers are meant to "contain", not to just package. To me, Singularity is more a "virtual environment on steroids", and it works great in that sense. But it doesn't "contain".
The hard truth is that Singularity was designed more to address a cultural problem in the HPC space (adoption friction and push back of new, "foreign" technologies) rather than to engineer a proper solution the the dependency hell problem.
HPC clusters still use Linux users and shell access, meaning that it is up to the user to run the container: there is just no container orchestration. This means that the user has to issue a command like "singularity run" or "docker run". And since not long time ago, to let users do a "docker run" it meant to have them part of the docker group, which is a near-root access group. Just not doable.
Singularity also works more or less out of the box with MPI in order to run parallel workloads, either locally on multi-nodes. However, this has a huge price as it relies on doing an "mpi singularity run", and it requires to have the same MPI version inside and outside the container. To me, this is this is more a hacky shortcut than a reliable solution.
I believe that the definitive solution in the HPC word will be to let HPC queuing systems to run and orchestrate containers on behalf of the users (including to run MPI workloads), thus allowing to make use of any container engine or runtime, including Docker. I did some trials and it works well, almost completely solving the dependency hell problem and greatly improving scientific reproducibility. A solution like the one presented in the OP contributes in the discussion towards this goal, and I personally welcome it.
With respect to Singularity, I think they just had to name the project "singularity environments" rather than "singularity containers" and everything would have been much more clear.
[1] https://github.com/apptainer/singularity/issues/476
Exactly. Part of the appeal to consolidate all of our container images to use Debian-slim is the ability to optimise the caching of layers, both in our container registry but also on our kubernetes cluster’s nodes (which can be done in a consistent manner with kube-fledged[1]).
[1] https://github.com/senthilrch/kube-fledged
Project mention: Lazytainer: Monitors network traffic and runs or stops containers accordingly | news.ycombinator.com | 2024-03-31
Notary v2: The evolution to Notary v2 brought improvements in signature portability and integration with third-party key management solutions. However, it does not provide a certificate authority, leaving public key discovery for open-source image verification as an unresolved issue.
NOTE:
The open source projects on this list are ordered by number of github stars.
The number of mentions indicates repo mentiontions in the last 12 Months or
since we started tracking (Dec 2020).
Go Container related posts
-
Rootless Docker in a Multi-User Environment – It's All About Context
-
Docker Private Registry using Harbor
-
A handsome k8s cluster - Is it possible?
-
Mykube - simple cli for single node K8S creatiom
-
GitHub - guyst16/mykube: k8s-installer - One-click k8s single-node cluster installation on your own device.
-
A gopher’s journey to the center of container images
-
Automating Kubernetes Deployments with FluxCD for Patched and Signed Container Images
-
A note from our sponsor - InfluxDB
www.influxdata.com | 2 Jun 2024
Index
What are some of the best open-source Container projects in Go? This list will help you:
| Project | Stars | |
|---|---|---|
| 1 | Harbor | 22,716 |
| 2 | ko | 7,312 |
| 3 | buildah | 7,080 |
| 4 | kubeedge | 6,476 |
| 5 | kraken | 5,909 |
| 6 | serving | 5,418 |
| 7 | kruise | 4,420 |
| 8 | devspace | 4,132 |
| 9 | automaxprocs | 3,844 |
| 10 | CDK | 3,692 |
| 11 | go-containerregistry | 2,992 |
| 12 | singularity | 2,495 |
| 13 | do | 1,639 |
| 14 | kube-fledged | 1,216 |
| 15 | wg-access-server | 592 |
| 16 | container | 541 |
| 17 | Lazytainer | 514 |
| 18 | connaisseur | 420 |
| 19 | hub-tool | 317 |
| 20 | notation | 297 |
| 21 | Eru | 241 |
| 22 | terrier | 226 |
| 23 | hiboot | 182 |
Sponsored
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com