HN user
For a more full fledged use case FRRouting may be the way to go. We are using Quagga here mainly to maintain internal routes with iBGP and route reflectors. This is a fairly simple use case.
Quagga is available in the default package managers of most distros so its a good place to start.
We have been working on a simplified container build system which does away with layers altogether. [1]
The use of layers at the build stage adds a lot of needless complexity with very little benefits and users really need to step back and question the value they are getting from the use of layers. [2]
Words like 'immutability', 'declarative' and 'reproduciblity' are often used in ways that can lead to user misunderstanding and can be accomplished with simpler workflows. For instance immutability, reuse, composition do not require layers. There needs to be a lot more technical scrutiny to avoid confusion.
[1] https://www.flockport.com/docs/containers#builds
[2] https://www.flockport.com/guides/say-yes-to-containers.html
We need to spin up a lot of VMs of various Linux distributions for testing Flockport and we found the existing tooling too heavy and involved.
In the end we rolled our own solution that is much more lightweight, uses QEMU directly and provides better visibility, ease of use and even some potentially useful networking features. Here are a few screencasts [1].
This is mainly designed as a module for Flockport and we will preview this soon.
What is wrong with Docker? This does not address any technical or other shortcoming and only seeks to replace one set of over engineered tools with another with the exact same problems. [1]
The is yet more of the ecosystem continuing to push over engineered tooling and 'winners' breathlessly without basic technical scrutiny that leaves end users dealing with needless complexity and debt.
Containers can be useful as a lightweight, efficient alternative to VMs and those who want containers untouched by questionable ideas should try the LXC project on which all this was based.
Any additional layer on top of this be it non standard OS environment or layers should meet technical scrutiny for end user benefits and most users will be surprised by the results.
This is where containers can help. Ubuntu ships with LXC and its relatively simple to download an Alpine Linux container and then install Nginx and you are set. Alternatively Flockport [self plug] provides an open source app store [1] for LXC and you can download a prebuilt Nginx114 container all set to go.
But containers are some work with both upsides and downsides and upsides compared to having it out of the box in the distribution.
@vikrant Glad to hear that! Networking in Linux is incredibly feature rich and the LXC team have done a great job on container networking.
Layers are integral in Docker, layers were pushed as enabling reuse, composibility, 'immutability', every 'run' statement is a layer. They are not an implementation detail. Managing all these layers adds complexity and impact users from choosing storage drivers, to using layers to building images, and if you are going to use layers you need to be a privileged user to mount all these layers. [1]
Here is an example. I build an Nginx container with no layers from a base alpine image. Users can download and run it in a layer so the original Nginx container remains untouched or run a copy of it. If there is a security alert or update I rerun the build. No layers used. You build the same Nginx container will multiple layers, and have all the overhead of tracking and managing these layers. And users then download the Nginx container made up of all these layers and run it. If there is a security update in any lower layers it needs to rebuild. You have used a workflow and designed an entire system based on stacking layers to compose and build your image. That is a lot of overhead and complexity in basic image management. What is the benefit?
[1] https://kinvolk.io/blog/2018/04/towards-unprivileged-contain...
Docker was based on LXC and there are some important differences that should be more well known.
The main difference is LXC boots an init in the namespace as the first process so you get a standard OS environment with multi-process support. Docker runs the application directly so you get a single process environment, unless you decide to run a process manager. IMHO this creates far more problems than it solves as anything nonstandard would, as you now need workarounds for basics like logging, networking, daemons and anything that expects a standard OS environment
Docker also uses layers to build containers and ephemeral data. None of these 3 critical decisions have seen much technical scrutiny resulting in persistent confusion in the ecosystem and with scrutiny many users will find they can add far more management overhead and complexity to containers. We have written about some of these issues here. [1]
For instance OP is referring to unprivileged containers and user namespaces that let you run containers as a user process. LXC has supported these since 2013. Docker added user namespaces support in recent versions. However taking just one issue - because of the use of layers to build containers you can't use unprivileged containers for app builds as only root users can mount filesystems. So a lot of these decisions have all kinds of tradeoffs that should be better known and discussed. [2]
Disclaimer: Founder at Flockport and trying to build a simpler alternative with LXC with support for app builds, provisioning, orchestration, service discovery and an app store. [3]
[1] https://www.flockport.com/guides/say-yes-to-containers.html
[2] https://www.flockport.com/guides/understanding-layers.html
Layers are interesting but the benefits of layers are vastly overstated, you can achieve the same without layers and the overhead and complexity in image management. Piling layers upon layers to build a container is a really bad idea and adds a lot of complexity in basic image management. [1]
The big problem is technical decisions like the use of layers, single process containers and ephemeral storage that add a lot of complexity and overhead have not met technical scrutiny and thus not well understood. But they should be as they can add a lot of management overhead and debt. [2]
Many users who use LXC will realize a lot of benefits and flexibility actually flow from containers and not these 'modifications'.
Disclaimer: Founder at Flockport and trying to build a simpler alternative with LXC containers.
[1] https://www.flockport.com/guides/understanding-layers
[2] https://www.flockport.com/guides/say-yes-to-containers.html
Thanks for the feedback. This is far from negative. There is definitely value in comparative docs that lets users get a quick overview, and we will put one together.
However we also want to start new conversations in the community about containers and orchestration and reach users who find existing platforms too complex. And we have put together a lot of content to kindle these discussions.
More technical scrutiny could lead to simplification and lower barriers for both users and developers.
Glad to hear you are aware of Flockport. Flockport was initially conceived as an app store for LXC containers. This was still in the early days of containers when the awareness was just building.
We always wanted to do more and our early vision was for a container management platform that is more accessible and easier to use and now of course we have built out a whole platform that delivers a lot more functionality and capabilities, and hopefully delivers on some of that early vision.
We are pleased to preview Flockport with the HN community. Flockport is a new container management platform designed to deliver a lot of functionality and ease of use. We designed this to be simple, it was the core driving force and we hope we have succeeded.
Flockport lets you quickly provision servers and deploy and manage containers across servers, supports overlay networks, distributed storage, service discovery, load balancers and high availability.
Flockport also provides a container build system and an app store. Apps can be deployed cluster wide. We also built in support for rolling out things like databases across clusters. Users can add and remove both database instances and also individual databases cluster wide. There is also similar support for web servers and load balancers builtin.
We are eager to have the community give it a go and get their early feedback and support. For those who do not want to install it there are preinstalled VMs on the downloads page and also screencasts on the resources page.
You can try LXC containers by Ubuntu, this is what Docker was based on initially. The main difference is LXC runs an init in the container so you get a standard multi process OS environment while Docker containers are single process environments.
We have been working on Flockport [1] that supports LXC containers and provides orchestration, an app store, service discovery and repeatable builds. It's still in early preview and we have not started proper outreach but it may be worth looking at.
Ubuntu also provides the LXD project that provides some orchestration across servers.
We have a guide [1] up on using Wireguard and go into some detail on the configuration and how it works. But we mainly use it to build container networks.
[1] https://www.flockport.com/guides/build-wireguard-networks.ht...
An app store, provisioning servers, overlay networks with vxlan, bgp and wireguard, distributed storage, service discovery and a build and packaging system.
We have tried to provide a lot of documentation so do visit if you want to learn more.
LXD is excellent and is by the authors of LXC. A lot of users may not need a lot of the functionality Flockport provides.
Flockport uses a standard networking bridge served by a Dnsmasq instance that all containers connect to. They all get their IP by DHCP unless you set static IPs and can be discovered by their name on local systems.
The DB command basically rolls out a fresh Mysql or Postgresql container instance and sets up the databases. The discovery happens over dns.
Flockport supports LXC so both aufs and overlayfs are available for use but not enforced. Flockport let's you launch containers in a layer so its used at run time if required but not to build containers.
Layers are interesting but they are still maturing and have hard to detect bugs and incompatibilities [1]. The more layers the worse it becomes so they can add management overhead. Containers and layers are separate technologies so its useful to leave it as a choice.
The benefits have also often been oversold. For instance reuse, all container platforms provide a library of base OS images. These can simply to used as required instead of trying to use layers. How many upper layers are there going to be on top the base OS that can be reused? This sounds good as an idea but often does not pan out, usually its just the base OS or base OS plus dev environment being reused so why use layers?
And If there are updates to any of the lower layers for instance security or version updates usually the container needs to be rebuilt so again you are not benefiting from using layers to build containers.
Using it at run time like you would run a copy of a container to keep the original intact still makes sense, but using it to build containers adds a lot of complexity and management overhead.
Thanks for that, that's a mistake, will get it corrected asap.
Unfortunately Selinux can interfere with processes in weird ways without clear messages to end users. When a container starts networking devices are created, if using layers or btrfs/zfs overlays or snapshots may be created, bind mounts activated. There is a lot of potential for permission issues.
Similarly when creating overlay networks ports across systems need to be open. The idea behind this is users can ensure the functionality is working as desired before enabling firewalls and other security features so they can debug issues effectively.
We have tried to provide a lot of documentation so new users can get started and get comfortable with containers and networking. Often users get discouraged if even after following the docs they run into issues.
Hi, the build system is quite flexible. It's used to build all the open source apps currently available in the app store.
That DB keyword basically allows you to roll out a linked database container for your app if required. Only Mysql and Postgresql is currently supported. These are Mysql and Postgresql instances that can be used for this.
A lot of apps require databases and instead of configuring it manually this allows some degree of automation so a linked database container can be easily deployed if required.
We have a container basics article [1] that provides a quick overview of Linux containers including differences between LXC and Docker containers.
Linux containers are made possible by the addition of Linux namespaces to the kernel in 2.6. A namespace allows you to launch an isolated process. There are 6 main namespaces including a network namespace and container managers basically launch the container process in a new namespace.
LXC is a userland container manager in development since 2008. Docker was initially based on LXC in 2013 and later developed their own container manager in Go.
LXC launches an OS init in the namespace so you get a standard multi process OS environment like a VM. Docker launches the application process directly so you get a single process container. Docker also uses layers to build containers and has ephemeral storage.
So LXC containers behave more or less like lightweight VMs. Docker is doing a few more things that need to be understood.
We are working on a project with standard LXC containers [1] which tries to make orchestration and some of this stuff especially networking simpler.
We support provisioning servers, building overlay networks with Vxlan, BGP & Wireguard, distributed storage and rolling out things like service discovery, load balancers and HA.
It may be worth exploring for those struggling with some of the complexity around container deployments. At the minimum it will help you understand more about containers, networking and orchestration.
LXC on which Docker was based always had a much more sensible container model and contrary to the pervasive misinformation by the devops ecosystem is far easier to use.
It supports a standard OS environment and does not enforce the use of layers so users don't have to deal with single process non standard OS environment which removes half the complexity.
We are working on a project, Flockport, that supports LXC and provides an app store, orchestration, networking, distributed storage, service discovery and HA. So there are attempts to explore simpler alternatives.
This is not limited to Apple. Top phone prices including Galaxy, Pixel etc have been steadily creeping upwards yearly starting from $500 and are now at $800-1000. Next year it could well be $1200 and in 3 years $1500.
Has the fundamental tech in the phones dramatically increased to justify this, not really.
The same applies to ultrabooks with low performance heavily throttled dual core chips, going from $700-800 to now $1500 plus. This applies to macbooks, dell xps, surface, hp and even lower cost alternatives like Asus.
There is a trend of sorts and it may well be rising income disparities means those at the top are not price sensitive and will pay $500 or $1500 with little qualms, and marketers are responding to the market.
The first choke point is the ISP. You are completely dependent on the ISP or mobile provider to get on the network. Once on the network there are multiple choke points around IP addresses, dns, ca authorities, registries and more.
As long as you are dependent on anyone to get on the network it by definition can't be decentralized. Consumer wireless tech is heavily regulated and governments are extremely paranoid about communication channels they don't control and can't monitor.
This is unlikely to change because there are no incentives to develop technology that truly empowers individuals, there is no profit in it, it's a social good. If developed it will be demonized and made illegal, and limited to minority dissenters, the general population is unlikely to go through hoops to get on a network.
This really feels like another world. Here is a confession, I have stopped believing people need to be informed, to be made aware.
I think most of us, adults know exactly what is happening, the consequences of capitalism, the reality of our societies, the reality of poverty, the reality of a large number of people struggling, suffering, sad, desperate, unhappy.
We have a sophisticated mental model to deal with it, we pretend it doesn't exist, untill you are absolutely forced to confront it, at which point you may signal, posture, be shocked, but life goes on. Our systems fundamentally and deeply reward unethical behavior and greed, and humans are survivors, we survive.
There has been a clear betrayal of the people. All the loud claims of freedom and liberalism by techies from the 90s has come to nought and infact moved the other way. Techies have dropped any pretense of ethical behavior and are hiding behind user ignorance to abuse them.
Google, Facebook and others creepy surveillance behavior has been more or less normalized and few seem to have a problem working for them and furthering their agendas. Once the infrastructure for surveillance exists, things change whether you like it or not.
You can't be a victim all the time, at some point you need to take responsibility, if you can behave with integrity you can't expect it from society.
Why single out Uber, Google, Facebook and others appear to be neck deep in equally if not more shady activity. Infact most of SV is, Palantir come to mind and seem by media reports to be infinitely worse and a lot of this behavior has been normalized so many do not find it particularly objectionable.
The posturing about Uber is valid but the zeal seems a touch misplaced or this board would be full of similar opinions about others.
It's interesting you choose to frame overwhelming dissent and anger at shady behavior as a 'mob'.
By summarily dismissing a bunch of legitimate concerns by multiple users you are basically saying users don't matter.
That kind of ivory tower attitude never worked well without leverage.
Containers are useful and provide many advantages compared to VM's but as an industry many will acknowledge there is a real risk of putting people off containers due to ballooning complexity. Flockport is a small step towards providing a simpler alternative.