91–100 of 190 posts
So this is pretty misleading. It's really a full system emulator (qemu) running inside Docker, using root privileges on the container that make the isolation very weak (--privileged). It also uses hardware assisted virtualization (KVM) which is not going to be available most of the time Docker is. You can think of the Docker platform itself as subset of the Linux platform. With many common features removed by default…
It's hard to see what Docker is adding here since qemu is being run inside Docker. You could get almost identical functionality out of a bare VM image and not deal with the hassles of docker.
Aren't you being a little too harsh? The Dockerfile automates the installation of libvirt and custom components to launch the VM so while the title might be misleading it is hardly "not adding" anything.
So this is pretty misleading. It's really a full system emulator (qemu) running inside Docker, using root privileges on the container that make the isolation very weak (--privileged). It also uses hardware assisted virtualization (KVM) which is not going to be available most of the time Docker is. You can think of the Docker platform itself as subset of the Linux platform. With many common features removed by default…
I don't care though. What I care about is that it's a pain in the butt to do CI/CD pipelines for an application with iOS/OSX support. So if someone has a headless OS X contraption on offer, I want to hear some more about it. The last time I set this up, a manager decided he wanted a laptop like the rest of us instead of the iMac he got. He asked semi-jokingly if someone wanted the machine for anything and I said "Yes…
This project relies on OSX-KVM, which is a thing that already exists. The dockerization of that project (what this post is about) is a gimmick as described by GP.
I just want a good CI/CD system for macOS to build iOS apps without needing to buy a farm of Mac Minis, or even buy a Mac, is that too much to ask?
I just want a good CI/CD system for macOS to build iOS apps without needing to buy a farm of Mac Minis, or even buy a Mac, is that too much to ask?
Github Actions has macOS builders. Not sure if they have XCode installed, though.
Earlier quoted context omitted.
Although it's slowly being migrated to GitHub (though they won't officially admit it), DevOps is a great service with a lovely UI. The pipeline docs are somewhat lacking though IMHO but once you get them working, they work great.
I've been worried about Azure DevOps getting merged into GitHub since Microsoft bought Github, but thankfully I haven't seen any drop in the maintenance of Azure DevOps, not yet anyway. As much as I like Github for OSS projects, I really love Azure DevOps for everything else. The CI/CD capabilities are amazing, and I haven't had any real issues with lack of documentation (a few small things here and there for sure th…
Earlier quoted context omitted.
I work at Sourcegraph and have been considering something like this for a while for running long-running jobs, things like CI pipelines and GitHub actions for example. How would you feel about an app like GitLab, for example, shipping a docker container that required privileges for this, I wonder?
It'd definitely be a harder sell for third party software to require a privileged container and /dev/kvm mounted when you run it in your environment, especially since nested virtualization is largely unavailable in AWS. It also requires that the correct kvm kernel module is loaded, etc. However, if it was a product that required virtualization and that was recognized as a requirement, then also distributing a docker…
Earlier quoted context omitted.
I think "docker" is an ambiguous term nowadays. Depending on your point of view, it could denote a container, or source control, or a sort of makefile. To me it is a reproducible recipe in 43 lines of Dockerfile text.
Okay, I know how docker can mean containers, and I agree that Dockerfiles are quite similar to makefiles, but how does docker relate to source control?
maybe "docker history" ~ "git log"?? tags=branches?
Docker isn't one thing, so it's ALL grey. It's not really make. It's not really a vm. It's not really even reproducible.
One thing is for certain - it's hard to describe docker to new folks so they get it. "it's sort of like netflix, for cows, but in space..."
So this is pretty misleading. It's really a full system emulator (qemu) running inside Docker, using root privileges on the container that make the isolation very weak (--privileged). It also uses hardware assisted virtualization (KVM) which is not going to be available most of the time Docker is. You can think of the Docker platform itself as subset of the Linux platform. With many common features removed by default…
It's also been done before: https://github.com/kholia/OSX-KVM
So this is pretty misleading. It's really a full system emulator (qemu) running inside Docker, using root privileges on the container that make the isolation very weak (--privileged). It also uses hardware assisted virtualization (KVM) which is not going to be available most of the time Docker is. You can think of the Docker platform itself as subset of the Linux platform. With many common features removed by default…
I think "docker" is an ambiguous term nowadays. Depending on your point of view, it could denote a container, or source control, or a sort of makefile. To me it is a reproducible recipe in 43 lines of Dockerfile text.
Why do we do this to ourselves? Words have meaning. This should go doubly so for engineers. Our language should be as precise as possible when describing systems.