[HN Gopher] Flatcar Container Linux
___________________________________________________________________
Flatcar Container Linux
Author : thunderbong
Score : 115 points
Date : 2023-04-09 15:57 UTC (7 hours ago)
(HTM) web link (www.flatcar.org)
(TXT) w3m dump (www.flatcar.org)
| Erlangen wrote:
| Is this a fork and continuation of coreos? Tracking down the git
| log, a lot of commits were made by coreos and redhat employees.
| vxNsr wrote:
| Appears to be a continuation of that project under a different
| name. Someone else pointed out that this one was acquired my
| Microsoft in 2021, but does appear to be receiving regular
| updates so it's not sunsetted yet.
| brancz wrote:
| Yes this is a direct fork. I happened to have been a CoreOS
| Berlin employee and know the kinfolk folks (now acquired by
| Microsoft) that did this fork after the Red Hat acquisition
| very well. I'm very glad they did, a lot of things I liked a
| lot about CoreOS container Linux unfortunately didn't make it
| into Fedora CoreOS.
|
| The kinfolk folks also run the update server to perform auto
| updates.
|
| //edit
|
| Continuation wouldn't be a wrong word either as it all
| coincided with the Red Hat acquisition. But I guess "fork" is
| correct since it's under a different name.
| avtar wrote:
| > a lot of things I liked a lot about CoreOS container Linux
| unfortunately didn't make it into Fedora CoreOS.
|
| Like what?
| brancz wrote:
| A couple of small things, but primarily I don't think it
| actually embraced immutability in the same way. CoreOS
| container Linux used A/B partitions for updating truly
| immutably. Partition B didn't boot? Just boot A again.
|
| Fedora CoreOS and RHEL CoreOS use OSTree [1], no shade on
| OSTree, it works well, but I slept better with A/B
| partitions, I just find them easier to reason about.
|
| [1] https://github.com/ostreedev/ostree
| dilyevsky wrote:
| It uses ostree but it's read-only root partition and
| changes only take place on reboot unless you pass a
| special flag
| jzb wrote:
| From Fedora CoreOS docs: " When an update is complete,
| the previous OS deployment remains on disk. If an update
| causes issues, you can use it as a fallback."
|
| IIRC RHEL now has tooling for automatic rebooting into
| the old version when checks are failed. Not sure how hard
| that is to do with Fedora CoreOS.
|
| Guess I'm not sure what functions are missing in these
| implementations that would cause you to lose sleep.
| brancz wrote:
| It's the same in spirit, but I just find the A/B
| partitions easier to reason about. To me it's about
| minimizing factors.
| avtar wrote:
| Gotcha. Thanks for clarifying.
| chubot wrote:
| This looks cool, but what's the dev environment like?
|
| I think Ubuntu is a popular base image in Docker because Ubuntu
| is popular for engineers to use on their desktops
|
| Debian usually passes for Ubuntu, since the package names are
| mostly the same.
|
| So either you do all your development in containers, or you have
| drift between the dev environment and the cloud.
| theodric wrote:
| > Debian passes for Ubuntu
|
| Ubuntu passes for Debian, you mean. Debian has been around
| much, much longer than Ubuntu and set the standards Ubuntu got
| for free and commercialized.
| MathMonkeyMan wrote:
| True, but devs like me started with Ubuntu. Then years later
| we see a Debian docker image and wonder how different it will
| be. Mostly the same, for the reason you mentioned.
| chubot wrote:
| Yes I know, but Ubuntu seems to be more popular as a desktop
|
| What I mean is that people just hack on stuff on their
| desktop. They install Python NumPy or Rails or whatever. Like
| gigabytes of dependencies.
|
| And then they want to deploy.
|
| Is it easy to do that with Flatcar Container Linux? How do I
| do it?
|
| Or is it easier to make a Docker file that does apt-get
| install X and pip install Y ?
|
| You can do that with Ubuntu as a base image, and Debian
| usually "just works" if you're on Ubuntu. (I'm doing this
| with our Debian CI images)
|
| Not saying you should always take the easier path, but I also
| think it's a good idea to minimize the differences between
| the dev environment and production
| vxNsr wrote:
| My understanding is that flatcar is for running your docker
| containers, not necessarily for building them.
| vidarh wrote:
| It's intended for a workflow where you build docker
| containers, and deploy docker containers, so the
| environment is identical. If all you deploy is containers,
| it makes sense for the host OS to be as small as possible,
| and as immutable as possible.
| joeatwork wrote:
| The intention is to do all of your development in containers,
| in whatever environment you choose, and then deploy the
| containers into production on a Flatcar cluster.
| thrill wrote:
| Applause to the group behind this.
|
| CoreOS "just the containers, ma'am" plus ChromeOS "set in stone"
| OS (but updateable) approach was so obviously good once you
| started using it that it was just begging to be picked up again.
| dilyevsky wrote:
| Cool project. Also see https://getfedora.org/coreos?stream=stable
| for Fedora-based CoreOS successor
| pelasaco wrote:
| or the openSUSE MicroOS https://microos.opensuse.org/
| seized wrote:
| Fedora IoT is an easy step to this as well. It's really
| "Silverblue server", rpm-ostree based but without making the
| jump to ignition files right away.
| kris-nova wrote:
| How does this compare to https://ublue.it/
| jcastro wrote:
| ublue is based off of fedora and rpm-ostree, which is what
| "CoreOS" is today.
|
| What happened was old school CoreOS was A/B partition based:
| https://github.com/coreos/docs/blob/master/os/sdk-disk-parti...
|
| My memory is hazy but here's how I remember it: After Red Hat
| acquired CoreOS they announced their intent to rebase the
| entire thing around rpm-ostree, which is the CoreOS people know
| today: https://coreos.github.io/rpm-ostree/
|
| At the time there was some anxiety in the community as to what
| would happen, as there was no direct upgrade path from old
| CoreOS to new CoreOS. Theoretically if we all believed the
| kool-aid we were drinking it's just a redeploy, no pets!
|
| Kinvolk came along, forked it, and made Flatcar Linux, which
| kept the A/B partitioning system, and more crucially, let you
| just change a config file and all your old CoreOS nodes would
| just move to Flatcar and then you were good to go. So now if
| you wanted to stay on the system you were comfortable with you
| could just use Flatcar. If the composability of rpm-ostree
| attracted you then new CoreOS have you covered. Red Hat
| deserves a hat tip here because in their documentation/blog
| they explicitly mentioned Flatcar as an option for people who
| wanted to stick with what they know, which I thought was cool
| and how I discovered it!
|
| Later on Microsoft acquired Kinvolk and and then people raised
| eyebrows. I have not checked in a while but the folks involved
| continued to do their thing and run it like a good OSS project,
| hold public meetings, all that stuff. Microsoft gets a good hat
| tip here.
|
| I use both and they're both high quality.
| haarts wrote:
| I've been reading a bit but it seems you can't add containers
| after you have booted the Flatcar distro. So define it on first
| boot or reinstall?
| dilyevsky wrote:
| No not quite. You can even add new systemd units at boottime -
| there's a special ignition config for that
| blixtra wrote:
| This is incorrect. It's an immutable OS. But containers can be
| started and stopped as much as you want. It's the sole purpose
| of Flatcar.
| moondev wrote:
| Comparing Immutable infrastructure with cloud-init vs immutable
| filesystem with ignition. What advantages would flatcar provide.
| mdaniel wrote:
| Ignition is a tire fire and I despise it with all my heart.
| It's made worse by there being like 5 different incompatible
| under-documented versions each with their own cutesy bugs
|
| In last contact I had with Flatcar (before we moved to
| Bottlerocket) one could still use cloud-init yaml even with
| Flatcar so that's what I'd recommend instead of trying to read
| through the unbounded number of github issues trying to track
| down why simple things don't work with ignition
|
| As for "what advantages Flatcar provides," the answer is always
| "in comparison to what?" I haven't run a general-purpose OS in
| production in over 8 years, and I don't intend to ever go back
| to having a mutable OS. There are just too many opportunities
| for randos to "just ssh in and do this one thing" and then I
| have to spend hours tracking down why some machines behave
| different from their peers
| pengaru wrote:
| > Ignition is a tire fire and I despise it with all my heart.
|
| Could you elaborate on this? I helped [1] create Ignition
| with Alex Crawford [0], its original author, while @ CoreOS
| in ~2015. To call what we were making then a "tire fire"
| seems comically hyperbolic for what was such a rudimentary
| bootstrapping tool, and generally unexpected for something
| we'd ship.
|
| Has its scope grown out of control since those early days, or
| has it been mismanaged? We're coming up on a decade since my
| involvement...
|
| [0]
| https://github.com/coreos/ignition/commits?author=crawford
|
| [1] https://github.com/coreos/ignition/commits?author=vcaputo
| mdaniel wrote:
| Ultimately I'm sure I'm going to be sorry I weighed into
| this, because maybe it's just personal preference and I'm
| not going to change anyone's mind and you are
| unquestionably not going to get me to ever touch that
| again. And I'm sorry if your feelings are hurt, and I
| appreciate that you and your coauthor know and love the
| system but my experience with it mirrors that Microservices
| YouTube joke
|
| My biggest heartburn is that I have[1] to _compile_ a boot
| configuration document. Some of that may be a concession to
| Ignition being inexplicably written in JSON, but it 's
| possible the transpiler does some massaging and
| restructuring of keys, I dunno, I didn't want to compile a
| boot document
|
| This is how one creates a file in Ignition:
| https://coreos.github.io/ignition/examples/#create-files-
| on-...
|
| Contrast that with https://cloudinit.readthedocs.io/en/20.1
| /topics/examples.htm...
|
| I grant you that
| https://coreos.github.io/butane/examples/#files may be the
| example of pre-transpilation using the `inline:` structure
| but for my use case of authoring that UserData dynamically,
| I don't have a `!TranspileUsingCuteNameOfTheDay` in
| CloudFormation
|
| And since I haven't had my hands on the Flatcar ecosystem
| in a few years, I'm not going to have access to the very
| specific pain points of "well, this cutesy named thing is
| broken because it depends on this other cutesy named thing"
| but what it boils down to is cloud-init behaves sanely, has
| been around forever, and can be authored easily in a bunch
| of different circumstances
|
| fn-1: yes, I can appreciate it's "just a JSON document" but
| no reasonable person is going to author JSON string
| literals containing data: URIs for contents
| jzb wrote:
| "Ultimately I'm sure I'm going to be sorry I weighed into
| this"
|
| Maybe you wouldn't be if you didn't use phrases like
| "tire fire" at other people's work?
|
| It sounds like Ignition isn't your cup of tea, which is
| perfectly fine and few people could take issue with that.
| Tire fire is unnecessarily caustic and doesn't really
| improve the discussion.
| pengaru wrote:
| So if I understand correctly, "I don't like RFC 2397 and
| JSON" == "tire fire"?
| mdaniel wrote:
| I guess if you found my comment to be "comically
| hyperbolic" then replying to mine with a "comically
| reductionist" is fair game
|
| So, anyway, I actually did dig up a concrete example of
| my experience with it, and I cannot link to the
| "Additional information" section but that is both why I
| think the thing was a mess and also why the Miroservices
| YT joke resonated:
| https://github.com/flatcar/Flatcar/issues/220
|
| I think the CoreOS boot strategy was decomposed into a
| bunch of different executables, each responsible for
| doing their own little slice of the world. Maybe it drew
| inspiration from systemd in that way. But, just like my
| real life experience with microservices, it requires
| keeping a bunch of different projects and their upgrade
| paths in ones head, knowing their disparate config
| formats, and when one of them inevitably has a bug,
| understanding how to troubleshoot what went wrong with
| _the system_ as a whole
|
| And, again in trying to be reasonable in this
| discussion[1] I do also understand why one would opt for
| the data URI, given how much of the rest of Ignition
| loads content from URLs. I don't believe cloud-init has
| that remote content paradigm baked into it nearly the
| same way, so I hear you about that.
|
| And yes, my belief is that JSON is a data-exchange format
| from _computer to computer_ and making people write them
| is a poor DX choice, IN MY OPINION. And, to reiterate, I
| know that CoreOS's perspective is that it _is_ a
| computer-to-computer transmission from the transpiler-
| project-o-the-day to the Ignition binary, but that is
| predicated on one having access to that transpiler binary
| in all cases, which is quite different from the problem
| that cloud-init is trying to solve
|
| fn-1: I'm sorry you got hurt by my "tire fire" outburst,
| and that evidently derailed this whole interaction, but
| it was _my experience_
| dottedmag wrote:
| I have one complaint about Ignition: its builtin file
| download functionality is too limited:
|
| - there is a limited amount of retries (5?), so a network
| hiccup can easily cause the download to fail
|
| - no control over which responses are fatal, so if you boot
| a VM with a config that references a URL that's still 404
| due to async nature of something, then only a single
| attempt is made.
|
| The company I work for uses Flatcar exclusively, but we
| don't use config chaining due to these limitations, and we
| have moved all file downloads to the shell scripts embedded
| into the config.
| quijoteuniv wrote:
| <<Flatcar Container Linux is maintained and developed by Kinvolk,
| a company that was acquired by Microsoft in 2021.>>
| intelVISA wrote:
| Thanks for the warning, almost fell for it...
| jaboutboul wrote:
| Comments like this are unhelpful and unproductive. That team
| is totally independent and does some great work and has
| continued to be a totally community driven project.
| snerbles wrote:
| Some people want to avoid tying their own projects to
| certain vendors, and this information is helpful to them.
| See also Oracle, IBM, etc.
|
| Microsoft has done quite a lot to rehabilitate their image,
| a decade ago few would be so quick to defend them.
| squarefoot wrote:
| > Microsoft has done quite a lot to rehabilitate their
| image
|
| I don't want to sound as a anti-MS fanboy, but that's the
| standard procedure when you get to the point "If you
| can't beat them...". Microsoft isn't to be trusted just
| because they're a business, but because like many others
| they're after profits above anything else. Just look at
| how they turned a potentially very decent OS (Windows 7)
| into worse privacy nightmare at every new version. I
| simply don't want them to mess with Linux.
| intelVISA wrote:
| I appreciate where you're coming from but unfortunately I'm
| not able to support software that is backed by harmful
| corps like MS.
| nimbius wrote:
| Kinda related, but a flatcar was historically a kind of railcar
| you could mount shipping containers, chassis and large +100 short
| ton loads onto.
|
| These days we call them intermodal frames or an intermodal
| chassis. It can go from rail to cargo ship to truck to plane, and
| its all highly standardized and scalable :) CSX even uses them to
| test their robotic conductor/ automated locomotive technology
| PuffinBlue wrote:
| They mention the name association in the FAQ.
|
| [0]https://www.flatcar.org/faq#what-is-the-significance-of-
| the-...
| mixdup wrote:
| I mean flatcars are still used today (not just historically)
| for things like tanks, farm equipment, lumber, semi-trailers,
| and sometimes even standard containers
| (https://en.wikipedia.org/wiki/Flatcar)
|
| Cars that carry containers are now mostly referred to as well
| cars (https://en.wikipedia.org/wiki/Well_car)
|
| An intermodal chassis or frame usually refers to the highway
| version used to pull a container behind a truck
| (https://en.wikipedia.org/wiki/Container_chassis)
| trustingtrust wrote:
| There is one for arm64 is there one for the rpi4 ? I already run
| containers on mine this would be even better.
| blixtra wrote:
| This might help you: https://github.com/flatcar-
| linux/Flatcar/issues/502
| moondev wrote:
| The rpi4 has uefi firmware available, this allows you to boot
| any generic uefi aarch64 image, you no longer need rpi specific
| images.
|
| https://github.com/pftf/RPi4
| monocasa wrote:
| It still needs to be an RPi specific image on the card as
| this firmware lives on the sd card too.
| sisk wrote:
| To add, modern u-boot has enough UEFI support that you can
| get away with using it instead of this full tianocore-based
| implementation.
___________________________________________________________________
(page generated 2023-04-09 23:00 UTC)