Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/cgwalters/coretoolbox
"pet container" tool using podman
https://github.com/cgwalters/coretoolbox
container podman rust
Last synced: 2 months ago
JSON representation
"pet container" tool using podman
- Host: GitHub
- URL: https://github.com/cgwalters/coretoolbox
- Owner: cgwalters
- License: apache-2.0
- Created: 2019-04-18T15:51:19.000Z (over 5 years ago)
- Default Branch: master
- Last Pushed: 2022-06-16T23:53:27.000Z (over 2 years ago)
- Last Synced: 2024-10-13T01:43:04.078Z (3 months ago)
- Topics: container, podman, rust
- Language: Rust
- Homepage:
- Size: 130 KB
- Stars: 24
- Watchers: 3
- Forks: 6
- Open Issues: 11
-
Metadata Files:
- Readme: README.md
- License: COPYING
Awesome Lists containing this project
- awesome_atomic - coretoolbox - Toolbx alternative in rust with a focus on container builds. (Older project, appears unmaintained, but if I don't include rust stuff people will get upset :smiley:) (Toolboxes)
README
coreos-toolbox
===
This is a new implementation of https://github.com/debarshiray/toolbox/
Installation
---
Be sure you have [cargo installed](https://doc.rust-lang.org/cargo/getting-started/installation.html).
Then:
`cargo install --git https://github.com/cgwalters/coretoolbox`
In the future we may invest in packaging this for different distributions, or
see about shipping it with e.g. podman by default.
Getting started
---
One time setup
```
$ coretoolbox create
$
```
Now, each time you want to enter the toolbox:
```
$ coretoolbox run
```
One suggestion is to add a "profile" or configuration to your terminal
emulator that runs `coretoolbox run` by default, so that you can
easily create new tabs/windows in the toolbox.
Rationale
---
In order to disambiguate in this text we'll call this tool
"ctb", and the other one "dtb".
The main reason to introduce a new tool is that dtb too strongly
encourages true "pet" containers, where significant state is stored
inside. We want to make it easy for people to build their own
toolbox "base images" derived from the upstream image. For example,
rather than doing `yum install cargo` inside a toolbox container,
you use a `Dockerfile` that does:
```
FROM registry.fedoraproject.org/f30/fedora-toolbox:30
RUN yum -y install cargo
```
The `toolbox` command should ideally have at least a basic
concept of a "build" that regenerates the base container, but
at a minimum should support more easily specifying that base image.
A related problem with dtb is that it actually does create
a derived image locally with e.g. the username added; this
forces the image to be specific to one user or machine.
What "ctb" does instead is inject dynamic state (username, `HOME` path)
into the container at runtime. This allows a lot more flexibility.
Today "dtb" has a hardcoded list of bind mounts for e.g. `HOME`
and the DBus system bus socket.
I ran into a case where I wanted e.g. the system libvirt socket.
In general, we aren't trying to confine `toolbox` - it's a privileged
container. So "ctb" takes the approach of mounting in most
things from the host into the `/host` directory, and then uses
symlinks into `/host`. This again makes everything a lot more
flexible as the set of things exposed can easily be changed
while the container is running.
Finally, ctb is written in a real programming language; bash
gets problematic once one goes beyond 10-20 lines
of code.
License
---
Licensed under either of
* Apache License, Version 2.0,
(./LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
* MIT license (./LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.