Current Trends in DC Networking - CoreOS Install
As I outlined in my last post, CoreOS Container Linux is not your traditional operating system. The same can be said about the base install of CoreOS.
Depending on the use case there are multiple deployment options for CoreOS. For cloud deployments all major providers are supported.
Amazon EC2 Container Service
Amazon EC2
DigitalOcean (DigitalOcean guide)
Microsoft Azure
Google Compute Engine
Source: Current Trends in DC Networking - CoreOS Install (//)
From http://blog.movingonesandzeros.net/
You said elsewhere something that indicated the install of CoreOS was not cut and dried... can you elaborate some more on that?
Quote from: deanwebb on May 24, 2017, 10:03:57 AM
You said elsewhere something that indicated the install of CoreOS was not cut and dried... can you elaborate some more on that?
So any other OS you mount an ISO or slap a DVD in and boot to it. Run through a wizard and your servers is setup with a starting state. You can login with root or another account created during setup and you are off.
Coreos does not install this way. You run a script "coreos-install" which goes out and pulls the latest version of the train you are looking for and installs it to a disk. That install has no user setup, package manager, or anything you normal have to use a system. Cant even login after a base install.
To set that stuff up when running the script you have to point it to a config file with everything you want setup (network, storage, users/groups, files, etc). This will then add that configuration during first boot. OR if installing to RAM during every boot. This is either a "cloud-config" or "Ignition" file you create.
So you cant mount a CoreOS iso to install. Have to have a functioning linux os already running which can write to (un-mounted) your primary drive. hence live boot CD.
So, it needs a network connection to get going, sounds like.
That, and a very carefully crafted config file... which leads me to a question...
How many configs did it take you to get a config file that worked the way you wanted it to work?
Network connection is a plus but you can always use a flash drive or local disk space. Script can be modified to pull from local resource.
It took me about a week to get my first cloud-config file working where I could login to a base set.
My blog topology extends two vlans down to the server and required more advanced config. Spent another week or so figuring out how to configure networkd through Ignition since cloud-config would not support.
But that is kinda the idea. You spend your time getting your cloud-config setup then install and scale-out of servers is just a click of a button or boot up of a box. this is for both cloud and internal servers.
i would love to hear the security take on CoreOS as well.
Its one of their key benefits.
Since its such a minimum install anything installed after is isolated to its own container. Services, applications processes everything. Now how you control what communicates between containers is still up for discussion. But the isolation aspect seems like a solid idea. Need to kill a service or daemon? Just shutdown the container.
True, having it install as little as possible is definitely a plus from a security aspect.