[HN Gopher] Painless Desktop containers for everyday development
___________________________________________________________________
Painless Desktop containers for everyday development
Author : user787837
Score : 55 points
Date : 2022-06-04 21:07 UTC (1 hours ago)
(HTM) web link (dock.orion3.space)
(TXT) w3m dump (dock.orion3.space)
| rvz wrote:
| Hardly a cross-platform solution like what the current Docker app
| does, with tons of moving parts which you are 1 upgrade away to
| breaking everything with that installation and its back to re-
| installing it again or wasting time digging down and trying to
| fix what went wrong for just one distro in the worst case.
|
| > You may not be able to run this default image under MacOSX,
| although dock scripts themselves are fully compatible.
|
| Probably developers using Windows are also unable to run this
| script as well. So I guess they are no better off with a 1 click
| install with Docker Desktop.
|
| It seems the video I saw had more than 2 steps. If it is really a
| 2 steps installation then it is 50 steps back when it all breaks.
| smoochy wrote:
| Author here: it actually doesn't break. Been running it for 1,5
| years. It's bash, there isn't much that can break. And it uses
| Docker cli with no hackery or experimental options.
|
| The only thing I am working on right now: a way to avoid
| building special images for MacBooks or ARMs, but rather have a
| patch-tool (a bash script, essentially), which would pull any
| image your like from Docker Hub and then run patches on it
| (patches are also simple, readable Bash scripts which would
| work kind of like migrations for DBs), so that you will quickly
| have a Dock-compatible image and if you wanted a Python or a
| Ruby env you'd use an extra set of included of patches or write
| your own.
|
| It sounds more complex that it would work, honestly.
| hhh wrote:
| I don't see the point of evading Dockerfiles. All of these
| customizations to me seem like they're just doing what you would
| do in a Dockerfile for creating a base image, but in a non-
| friendly way for people not using Dock.
|
| From reading, there seems to be planned support for VMs, which is
| where the mental click is for evading dockerfiles to me, but when
| creating VMs you have the same thing. The equivalent (in my mind)
| of this for VMs exists as Multipass, where you pass a cloud-init
| file for configuration.
|
| I think it's cool for playing, but if I could create a Dockerfile
| in the directory of the project, as simple as "FROM
| ubuntu:latest" and when I run Dock it takes this Dockerfile and
| then builds a new image ontop of it (with all these
| customizations, dropping me into a shell) _that_ is where this
| would shine to me. It may just be a workflow thing, but if I am
| building a container, I am already building Dockerfiles. They 're
| not _just_ for Docker, many many tools use them for containers
| more generically.
|
| The _painful_ part when building a container is when I am doing
| something decently involved (e.g. implementing a proprietary
| software daemon & driver for a German camera manufacturer that
| has to have custom udev rules and many, many customizations,) and
| just want to extend my natural terminal environment into that
| space to explore what's up. Then when I am done, I should be able
| to run docker build and get the clean, bare container. It's very
| rare that I just need an arbitrary container that will go away
| when working on a _project._ Periodically I may generate an
| ubuntu pod or something, but it goes away fast and generally
| lives for less than 10 commands.
|
| With that being said, I don't mean to poo-poo, as I do _really_
| like the aesthetic, the documentation is beautiful, and the
| thought put into it. I just don 't see where it fits into my (or
| many people I know)'s workflow pretty much strictly because of
| the Dockerfile thing. Some of the other tools look cool though,
| so I threw a buck or two in the hat :)
| smoochy wrote:
| Thank you. Yeah, I guess it's a matter of what you're used to.
| For me personally, I've never gotten used to Dockerfiles. It
| seemed like another configuration file format invented for
| nothing. With rules I had to remember. Entrypoint? Ugh. So I've
| just done everything in Bash, made it imply which
| container/image I want from $PWD and it saved me a ton of time.
| And, actually, I do tend to create/destroy containers quite
| often because of how easy it is (no editing files or eve
| providing cli arguments do `dock`).
|
| As for supporting VMs - you misunderstood. I meant support for
| other container engines. To me, it would most notably be BSD
| jails. In fact, if I get to it, I'd like to do something much
| more cool... Perhaps it would make sense to have a VM with
| FreeBSD running on a machine and then BSD jails running in it,
| all managed by a relatively small too-lset, such as `dock` -
| I'd probably have to rename or fork it. But the cool part of it
| all is that containers won't even depend on an architecture,
| since they'd be running inside a VM.
| coffeeblack wrote:
| Download some script and run the installer? Sounds like
| "setup.exe". How to be sure the site wasn't breached?
| user787837 wrote:
| We download, install and run scripts and binaries written in a
| variety of languages ALL of the time. This one's in Bash - even
| a child can sort of check it out. It is intentionally written
| in Bash and the code base is small (for this kind of project),
| so as not to obscure much.
| zamalek wrote:
| That is significantly more steps than Distrobox or Toolbox (2:39,
| vs probably 0:30), and it uses Docker and Ubuntu. Folks, we
| should be forever grateful what Docker and Ubuntu achieved but
| they have lived well into the "become the villain" territory.
|
| I have my containers built by Gitlab[1], and I jump into them
| with Distrobox. It honestly couldn't be simpler.
|
| [1]: https://gitlab.com/jcdickinson/containers/
| user787837 wrote:
| Wait, 2 steps for the installation are too many? :)
|
| On a serious note, I think it has been made clear this isn't
| intended _just_ for Docker, but any other container engine too,
| potentially. And from my experience using it every day, it
| saves a ton of time. As opposed to regular Docker usage
| patterns. I just navigate to my project directory and type
| `dock`. There is no need for any external service, such as
| Gitlab or even Docker Hub.
___________________________________________________________________
(page generated 2022-06-04 23:00 UTC)