[HN Gopher] Lightweight Alpine VMs on macOS
       ___________________________________________________________________
        
       Lightweight Alpine VMs on macOS
        
       Author : gandalfff
       Score  : 43 points
       Date   : 2022-11-28 02:44 UTC (2 hours ago)
        
 (HTM) web link (beringresearch.github.io)
 (TXT) w3m dump (beringresearch.github.io)
        
       | Sirened wrote:
       | it's a thin wrapper around qemu, for those interested
        
       | mberning wrote:
       | The container landscape is getting crowded. As a person who just
       | wants to get things done with containers it's not immediately
       | obvious where I should be focusing my efforts due to the
       | proliferation of "container solutions". It seems especially bad
       | on the mac right now.
        
         | syntaxing wrote:
         | Dockerfile + Docker compose is the way to go. With Portainer,
         | you'll be up and running in less than 30 min.
        
         | qbasic_forever wrote:
         | Colima is all you need now, it's basically a drop in
         | replacement for docker desktop. There are actually very few
         | container runtime engines (containerd and runc are the big
         | ones) and all the tools you read about just wrap that lower
         | level container runtime. They're all the same when you get down
         | to it and just have different opinions about config, networking
         | and storage.
        
           | idontwantthis wrote:
           | Every tool says its the same but they aren't. You'll
           | eventually run into some issue that wouldn't have happened on
           | Docker, and as soon as a dev spends two hours on it you've
           | paid more than you would have paid for a Docker Desktop
           | license for that dev for the year.
        
         | idontwantthis wrote:
         | I think you'd need a particular reason to not use Docker.
        
           | xmonkee wrote:
           | I do have a particular reason - memory use. I am running
           | postgres and redis locally for dev work, but I would love to
           | use Docker so that I can standardize it for my team, but it
           | just takes up to much ram on m1.
        
             | idontwantthis wrote:
             | I don't mean to sound flippant, but that sounds like you're
             | using a computer for business that can't handle the work
             | you are trying to do. If 32/64GB isn't enough memory then
             | yeah, I guess you need something else, but if your machine
             | has less than that then it sounds like you need to buy the
             | right computer for the job.
             | 
             | Also, are you using AMD or ARM images for those?
        
               | sqlcommando wrote:
               | I dunno about the m1 aspect of this but postgres and
               | redis for typical dev work shouldn't require more than a
               | gigabyte or two of RAM when running together. 32-64GB is
               | more like heavy traffic enterprise DB territory...
        
             | machiaweliczny wrote:
             | You can setup how much ram is allowed in docker. Generally
             | software will use as much as you allow (especially DB)
        
           | badrabbit wrote:
           | It takes more time and effort than just running the damn
           | script! Is that not good enough?
           | 
           | I mean I want to use containers but on top of setting up the
           | host, they require composing containers (even when ready made
           | for customizations), networking, logging and fight for more
           | memory when using memory hungry stuff in conjunction (like
           | elastic or other db).
           | 
           | If my main job was devops, I suppose I would make myself more
           | valuable by doing everything in containers but when I deploy
           | an app it is because I have to on top of many other duties so
           | being able to not only setup but troubleshoot and fix outages
           | quickly is most important (and I hope a full time devops
           | person, if I ever get one) will help me migrate all that some
           | day so it looks nice and neat.
        
       | reversethread wrote:
       | I don't see the point of a dedicated tool for this when it is
       | easy enough just to start a Alpine docker container with a couple
       | commands. As this project is just a wrapper for docker and LXD[1]
       | and those tools are already easy enough for the average SWE to
       | interact with, the project seems to just over-complicate an
       | already existing workflow.
       | 
       | [1] https://github.com/beringresearch/macpine#motivation
        
         | [deleted]
        
       | MBCook wrote:
       | So the automatic port forwarding/FS sharing/networking is nice if
       | you want that.
       | 
       | But I often don't. When I'm using Docker on my Mac it's usually
       | because I'm trying to use _Docker_. I need to use an existing
       | Docker container or build a new one to fit some purpose with a
       | Dockerfile.
       | 
       | I guess it's nice that there would be a simpler way to launch
       | one-off containers or containers for myself that aren't expected
       | to work like every other Docker container.
       | 
       | Is this a common need? Is there something that makes this more
       | than I've noticed? The fact I work in a "Docker for containers"
       | place may be preventing me from seeing what would make this
       | shine.
        
       | coderintherye wrote:
       | There's related discussion from earlier today at
       | https://news.ycombinator.com/item?id=33762657 for LXD
        
       | joshmn wrote:
       | Nice wrapper around qemu for those wondering.
       | 
       | As someone with MacAlpine heritage I have never been more
       | disappointed in two letters, though.
        
       | deafpolygon wrote:
       | This is your typical MacOS frenzy over solutions in search of a
       | problem space that didn't need solving.
        
       ___________________________________________________________________
       (page generated 2022-11-28 05:00 UTC)