Containers

• What is Kubernetes and how should you monitor it? - A monitoring strategy that takes advantage of Kubernetes will give you a bird's eye view of your entire application’s performance, even if containers running your applications are continuously moving between hosts or being scaled up and down.
• How to optimize Kubernetes resource configurations for cost and performance - in part two of this Kubernetes guide, you'll get help balancing appropriate parameter configuration for any cluster you are working with now or in the future. You'll learn about requests and limits, measuring CPU utilization, and how to optimize Kubernetes resource allocation.
• Best way to install and use kubernetes for learning - reddit
• Kubernetes The Hard Way - This tutorial walks you through setting up Kubernetes the hard way. This guide is not for people looking for a fully automated command to bring up a Kubernetes cluster. Kubernetes The Hard Way is optimized for learning, which means taking the long route to ensure you understand each task required to bootstrap a Kubernetes cluster.
• Deploying a Kubernetes Cluster within Proxmox using Ansible

Admin magazine has an article called Create secure simple containers with the systemd tools Nspawnd and Portabled, which offers a mechanism different from my favorite LXC mechanisms. I'll have to give it a try for simpler projects.

They seem to be subsets of the templates and caching already available via LXC, but the one stand out is an added tool called mkosi, which stands for Make Operating System Image, and is a tool for precisely that: generating an OS tree or image that can be booted. It seems to be useful for creating container images as well as images which can be used in heavier virtualization environments such as KVM.

Seen on the IQFeed Developer Support 2020/04/21. A solution for allowing ICMP packets.

iqconnect.exe does a ping round trip against its DTN servers (you can see the ping results at IQConnect.log when you stop the feed and iqconnect.exe exits). Thing is, ping uses ICMP protocol, which in linux is somewhat privileged.

So, you need to give wine the appropiate permissions in order to be able to use ICMP. Running wine as root in order to circumvent this problem would be overkill (besides a very bad thing to do!), but fortunately you can use setcap in order to grant permissions in a much more granular way.

First, locate where your wine-preloader file is. In my case, it's on /usr/bin/wine-preloader . Then, type (yoo will need to sudo for this):

sudo setcap cap_net_raw+epi /usr/bin/wine-preloader

and that's all. Now wine is allowed to use ICMP protocol, which in turn will allow IQconnect.eze to make its "ping things" without complaining

I am almost embarrassed to say that I missed a good night's sleep sifting through erroneous out of date misinformation, missing some subtle distinctions, and winnowing out the chafe.

This all started when I wanted to give Krita a try for editing photographs. It is said it is the next best thing in open source when compared to PhotoShop. When installed on my Debian Linux workstation, all I could get out of it was crashes of one form or another. I'm not really surprised as my workstation has been through various combinations of buster, testing, bullseye, sid and experimental. Some package is out of sync somewhere.

So.. since I know how to run LXC containers, I figured I'd give that a try. That was successful, to a point. I used X2Go for remote console. But when my images are Nikon NEF files at 24Megapixels at 14bits each, file size, computation, and visualization are a bit of challenge (the screen updates being the main challenge). A wide erasure brush was slow, even on my speedy machine.

There are sites which vehemently say that there is no direct way to see the GUI from a container on a workstation host. Sigh. Misinformation. Then there are the five year old sites which show how it is done, but have extra commands, missing commands, or missing options. More sigh.

After much trial and error and trying the same things over again, with minor variations on the theme, in the hopes something might fix itself, it was a long night.

For the record, here is my research on a Debian Bullseye system with LXC '1:3.1.0+really3.0.4-3' Continue reading "GUI From an LXC Container on the Host" »

To limit the amount of memory supplied to each container, place something similar to the following in the container configuration file:

lxc.cgroup.memory.limit_in_bytes = 5120M

The lxcfs daemon/service/package should be installed, and should be seen to be mounted on /var/lib/lxcfs

Prior to setting the memory limit, unfettered memory useage can be determined with

cat /sys/fs/cgroup/memory/lxc//memory.max_usage_in_bytes

When inside the container, something like 'free -m' should show the memory available to the container.

# free -m
              total        used        free      shared  buff/cache   available
Mem:          16029        5121        5890         444        5017       10046
Swap:          9535           0        9535

Here are some instructions I use to build a light weight gui in an LXC container. The window easily scales, and with Wine, Windows applications can be run without the Windows overhead.

Using X2Go Packages for Debian GNU/Linux as a reference, I created /etc/apt/sources.list.d/x2go.list with the following content:

# X2Go Repository (release builds)
deb http://packages.x2go.org/debian stretch extras main
# X2Go Repository (sources of release builds)
deb-src http://packages.x2go.org/debian stretch extras main

I have the following primary sources in /etc/apt/sources.list:

deb [arch=amd64] http://ftp.us.debian.org/debian          stable        main contrib
deb [arch=amd64] http://security.debian.org/debian-security stable/updates main contrib
deb [arch=i386] http://ftp.us.debian.org/debian          stable        main contrib
deb [arch=i386] http://security.debian.org/debian-security stable/updates main contrib

Then the following commands will add wine64, wine32, lxde, and x2go server:

vim.tiny /etc/apt/sources.list
apt update
dpkg --add-architecture i386 && apt-get update && apt-get install wine32 wine winetricks
apt update
apt --no-install-recommends install gnupg2 dirmngr
apt-key adv --recv-keys --keyserver keyserver.ubuntu.com E1F958385BFE2B6E
vim.tiny  /etc/apt/sources.list.d/x2go.list
apt update
apt-get install x2go-keyring && apt-get update
apt install \
  --no-install-recommends \
    xserver-xorg-core \
    xserver-xorg-input-all \
    xserver-xorg-video-fbdev  \
    xserver-xorg-video-vesa \
    lxde \
    x2goserver-xsession \
    x2golxdebindings

VNC client is not used. An X2Go client is used instead. It seems to be fast and efficient. And works through ssh. It can even do a proxied hop through one ssh connection to a second ssh destination.

Lifted from LWN [Posted February 10, 2018 by jake] -- In ACMQueue magazine, Bridget Kromhout writes about containers and why they are not the solution to every problem. The article is subtitled: "Complex socio-technical systems are hard; film at 11."

Don't get me wrong—containers are delightful! But let's be real: we're unlikely to solve the vast majority of problems in a given organization via the judicious application of kernel features. If you have contention between your ops team and your dev team(s)—and maybe they're all facing off with some ill-considered DevOps silo inexplicably stuck between them—then cgroups and namespaces won't have a prayer of solving that. Development teams love the idea of shipping their dependencies bundled with their apps, imagining limitless portability. Someone in security is weeping for the unpatched CVEs, but feature velocity is so desirable that security's pleas go unheard. Platform operators are happy (well, less surly) knowing they can upgrade the underlying infrastructure without affecting the dependencies for any applications, until they realize the heavyweight app containers shipping a full operating system aren't being maintained at all.

The original article is found at Containers Will Not Fix Your Broken Culture (and Other Hard Truths) -- Complex socio-technical systems are hard; film at 11.

My current role revolves around automating the build of solutions: operating systems, the networking, the virtualization, the storage and the apps running on top. And not just home grown software modules. So the above quote struck a chord. And is reinforced by another paragraph in the article:

Being able to reproduce a build allows for separation of concerns. We want this to be effective and yet not introduce unnecessary barriers. The proverbial wall of confusion is all too real, built on the tension between having incentive to ship changes and being rewarded for stability. Building just the right abstractions that empower independent teams is worth taking the time to iterate on (and, no, nobody gets it right immediately, because "right" will evolve over time).

While on the subject of containers, there was another recent LWN reference: Containers from user space in which Jonathan Corbet writes about Jessie Frazelle's talk at linux.conf.au 2018. The article reminds me that Seccomp, Apparmour and SELinux are important tools for enhancing the 'compartmentalization' of containers.

Containers, when used by developers for publishing their apps and dependencies, could be defined as a form of packaging. This definition segues into an article linked from Planet Debian which is called futures of distributions where the author makes reference to the issue:

The granularity at which software is built has fundamentally changed. It's now typical for hundreds of small libraries to be used by any application, often pegged to specific versions. Language-specific tools manage all the resulting complexity automatically, but distributions can't muster the manpower to package a fraction of this stuff.

2018/02/19 - even after saying all that, pre-built containers are here to stay: OpenFaaS -- you can package anything as a serverless function - from Node.js to Golang to CSharp, even binaries like ffmpeg or ImageMagick. I read somewhere that serverless is just something you can't ssh into. So there is a wall be built between those who build the underlying infrastructure and those who put the window dressing on. And is confirmed by OpenFaaS moto:

Our core values are: developer first, operational simplicity and community centric

Not saying serverless is good, bad, or ugly, but someone has a Curated list of resources related to serverless architectures and the Serverless Framework.

• Memory inside Linux containers: unanswered questions about how to check memory utilization within a container rather than the machine
• LXC 1.0: GUI in Containers by Stephane Graber, notes about non root containers, and running skype in a container.

I havn't tried it out yet, but from somewhere, I found cirros: CirrOS is a Tiny OS that specializes in running on a cloud.

Some documentation show how to get it into an lxc container.

Should run as a really tiny kvm?

I found in a Debian install that CirrOS is an LXC template (with the install of the LXC package):

# ls -alt /usr/share/lxc/templates/lxc-cirros 
-rwxr-xr-x 1 root root 10374 Aug 25 18:20 /usr/share/lxc/templates/lxc-cirros

An interesting repository encountered today:

cinf: A command line tool to view namespaces and cgroups, useful for low-level container prodding.