gvisor
for-mac
Our great sponsors
gvisor | for-mac | |
---|---|---|
64 | 93 | |
14,980 | 2,399 | |
2.7% | 0.7% | |
9.9 | 3.1 | |
6 days ago | about 2 months ago | |
Go | ||
Apache License 2.0 | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
gvisor
-
Maestro: A Linux-compatible kernel in Rust
Isn't gVisor kind of this as well?
"gVisor is an application kernel for containers. It limits the host kernel surface accessible to the application while still giving the application access to all the features it expects. Unlike most kernels, gVisor does not assume or require a fixed set of physical resources; instead, it leverages existing host kernel functionality and runs as a normal process. In other words, gVisor implements Linux by way of Linux."
- Google/Gvisor: Application Kernel for Containers
- How to Escape a Container
-
OS in Go? Why Not
There's two major production-ready Go-based operating system(-ish) projects:
- Google's gVisor[1] (a re-implementation of a significant subset of the Linux syscall ABI for isolation, also mentioned in the article)
- USBArmory's Tamago[2] (a single-threaded bare-metal Go runtime for SOCs)
Both of these are security-focused with a clear trade off: sacrifice some performance for memory safe and excellent readability (and auditability). I feel like that's the sweet spot for low-level Go - projects that need memory safety but would rather trade some performance for simplicity.
-
Tunwg: Expose your Go HTTP servers online with end to end TLS
It uses gVisor to create a TCP/IP stack in userspace, and starts a wireguard interface on it, which the HTTP server from http.Serve listens on. The library will print a URL after startup, where you can access your server. You can create multiple listeners in one binary.
-
How does go playground work?
The playground compiles the program with GOOS=linux, GOARCH=amd64 and runs the program with gVisor. Detailed documentation is available at the gVisor site.
- Searchable Linux Syscall Table for x86 and x86_64
-
Multi-tenancy in Kubernetes
You could use a container sandbox like gVisor, light virtual machines as containers (Kata containers, firecracker + containerd) or full virtual machines (virtlet as a CRI).
-
Firecracker internals: deep dive inside the technology powering AWS Lambda(2021)
An analogous project from Google with similar use cases is gvisor, which IIRC underlies Cloud Run: https://gvisor.dev/
-
Why did the Krustlet project die?
Yeah, runtimeClass lets you specify which CRI plugin you want based on what you have available. Here's an example from the containerd documentation - you could have one node that can run containers under standard runc, gvisor, kata containers, or WASM. Without runtimeClass, you'd need either some form of custom solution or four differently configured nodes to run those different runtimes. That's how krustlet did it - you'd have kubelet/containerd nodes and krustlet/wasm nodes, and could only run the appropriate workload on each node type.
for-mac
-
Emacs 29.1 Released
I use containers on Mac and Windows for development (and we deploy on linux). Docker for Mac is _unusably_ slow in my experience. The VM that it runs is a giant resource hog and a battery hog, and doesn't support ipv6 [0] Docker Desktop itself is (another) resource hog, wildly buggy, and painfully slow. It's the epitome of "shitty electron app".
On windows, docker desktop has all of the same issues as it does on mac. Docker's concept of volumes and file permissions on windows are nonsense. Windows updates and Docker Desktop regularly decide to disagree, [1] It's networking support interferes with other applications (like OpenVPN and the Xbox Game Center) [2].
[0] https://github.com/docker/for-mac/issues/1432
-
Error deploying subgraph on local
version: '3' services: graph-node: image: graphprotocol/graph-node ports: - '8000:8000' - '8001:8001' - '8020:8020' - '8030:8030' - '8040:8040' depends_on: - ipfs - postgres extra_hosts: - host.docker.internal:host-gateway environment: postgres_host: postgres postgres_user: graph-node postgres_pass: let-me-in postgres_db: graph-node ipfs: 'ipfs:5001' matic: 'matic:http://localhost:8545/' GRAPH_LOG: info ipfs: image: ipfs/go-ipfs:v0.10.0 ports: - '5001:5001' volumes: - ./data/ipfs:/data/ipfs postgres: image: postgres ports: - '5432:5432' command: [ "postgres", "-cshared_preload_libraries=pg_stat_statements" ] environment: POSTGRES_USER: graph-node POSTGRES_PASSWORD: let-me-in POSTGRES_DB: graph-node # FIXME: remove this env. var. which we shouldn't need. Introduced by # , maybe as a # workaround for https://github.com/docker/for-mac/issues/6270? PGDATA: "/var/lib/postgresql/data" POSTGRES_INITDB_ARGS: "-E UTF8 --locale=C" volumes: - ./data/postgres:/var/lib/postgresql/data
-
Docker Desktop is dead on Mac M1
https://github.com/docker/for-mac/issues/6867 This github issue might help. What worked for me was deleting the ~/.docker/buildx folder
-
Run Homebridge as a background service on Windows 11?
Well first off, this is a mistake. The official container is virtualized Ubuntu based image. So you have to virtualize it. I’m not even sure how you are using it because the network mode host isn’t supported.
- Docker sends usages even if you've opted out
-
Is it possible to get fast Rust compiles in a Docker container?
It seems to be a known problem: https://github.com/docker/for-mac/issues/3677 where people specifically mention hot reloading applications taking forever. Not sure exactly what is going on, but it is not Rust specific (devs mention Ruby, Java, etc.)
- Any replacement for Docker Desktop for Mac?
- install db locally or go with docker image for development?
-
How fast is 12th Gen Intel Core?
unfortunately it does it even if I kill all the containers. It's a well known issue and they have been circling around with attempted fixes, regressions etc for a long time [1]
-
How to run Minikube on Apple M1 chip without Docker Desktop
Weeks ago, while using Docker Desktop, it suddenly got stuck in a start-stop loop. I spent hours trying to resolve it, combed through GitHub issues and stackoverflow, and even downloaded older versions of Docker Desktop but to no avail.
What are some alternatives?
firecracker - Secure and fast microVMs for serverless computing.
podman - Podman: A tool for managing OCI containers and pods.
wsl-vpnkit - Provides network connectivity to WSL 2 when blocked by VPN
kata-containers - Kata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/
sysbox - An open-source, next-generation "runc" that empowers rootless containers to run workloads such as Systemd, Docker, Kubernetes, just like VMs.
UTM - Virtual machines for iOS and macOS
containerd - An open and reliable container runtime
KubeArmor - Runtime Security Enforcement System. Workload hardening/sandboxing and implementing least-permissive policies made easy leveraging LSMs (BPF-LSM, AppArmor).
WSL - Issues found on WSL
runtime - Kata Containers version 1.x runtime (for version 2.x see https://github.com/kata-containers/kata-containers).
podman-desktop - launch and setup vms for podman