#coreos systemd

[cloudshiftco]

How to Send Journald Logs From CoreOS to Remote Logging Server ?

https://cloudshift.co/gnu-linux/coreos/how-to-send-journald-logs-from-coreos-to-remote-logging-server/

How to Send Journald Logs From CoreOS to Remote Logging Server ?

CoreOS is an operating system that goes beyond the ordinary. When you need to send the journald logs to remote server, it will not be so simple but it is not too hard too.

First of all you can configure the rsyslogd but it will not send the journald logs. Journald daemon logs the events and outputs as binary file.  Only solution is to be able to read that journald via journalctl command line utility.  So this means we can not configure rsyslogd for sending journald logs to the remote logging server( Elasticsearch, Splunk, Graylog, etc… )

First of all we need to create a systemd configuration file for sending the logs to the remote.

# vi /etc/systemd/system/sentjournaldlogs.service Description=Sent Journald Logs to Remote Logging Service After=systemd-journald.service Requires=systemd-journald.service [Service] ExecStart=/bin/sh -c "journalctl -f | ncat -u RemoteServerIP RemotePort" TimeoutStartSec=0 Restart=on-failure RestartSec=5s [Install] WantedBy=multi-user.target

You need to change RemoteServerIP and  RemotePort  with your remote logging server’s IP address and service port.

If you are using or the remote logging server is listening on standard ports that will be 514. If you look closely to the ncat command there is -u argument which specifies that the connection will use UDP.  If you want to use TCP then please delete -u argument.

# systemctl daemon-reload # systemctl enable sentjournaldlogs.service # systemctl start sentjournaldlogs.service # systemctl status sentjournaldlogs.service

We need to reload systemd daemon and start the service.  That’s all.

[computingpostcom]

Podman (short name for Pod Manager Tool) is a daemonless container engine created to help you develop, manage, and run Open Container Initiative (OCI) containers on most Linux systems. Podman is an ultimate drop-in alternative for Docker. Podman is the default container runtime in openSUSE Kubic and Fedora CoreOS (certified Kubernetes distributions). You can use Podman to create OCI-compliant container images using a Dockerfile and a range of commands identical to Docker Open Source Engine. An example is podman build command which performs the same task as docker build command. In other words, Podman provides a drop-in replacement for Docker Open Source Engine. Some of the key advantages of Podman are: It run containers in rootless mode – Ability to run rootless containers which are more secure, as they run without any added privileges Native systemd integration – With Podman you can create systemd unit files and run containers as system services No daemon required – Podman have much lower resource requirements at idle since Podman is daemonless. Install Podman 4.x on CentOS 7 / RHEL 7 If you perform an installation of Podman on CentOS 7 / RHEL 7 from OS default repositories, an older version of the software is installed. Below is an output from a CentOS 7 Virtual Machine. $ podman version Version: 1.6.4 RemoteAPI Version: 1 Go Version: go1.12.12 OS/Arch: linux/amd64 In this article we are covering the installation of Podman 4.x on CentOS 7 / RHEL 7. The route to getting Podman 4.x on CentOS 7 / RHEL 7 system is by building the application from source code. Before we can proceed, uninstall any older version of Podman in the system. sudo yum -y remove podman Step 1 – Install Podman 4.x build tools Since we’re building the software from source, all the tools required must be installed. Ensure EPEL repository has been installed and is enabled in your system. sudo yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm Update all packages on the system and perform a reboot. sudo yum -y update sudo reboot Install Development tools on your CentOS 7 / RHEL 7: sudo yum -y install "@Development Tools" Install other dependencies by running the commands below: sudo yum install -y curl \ gcc \ make \ device-mapper-devel \ git \ btrfs-progs-devel \ conmon \ containernetworking-plugins \ containers-common \ git \ glib2-devel \ glibc-devel \ glibc-static \ golang-github-cpuguy83-md2man \ gpgme-devel \ iptables \ libassuan-devel \ libgpg-error-devel \ libseccomp-devel \ libselinux-devel \ pkgconfig \ systemd-devel \ autoconf \ python3 \ python3-devel \ python3-pip \ yajl-devel \ libcap-devel Wait for the installation of these dependencies to complete then proceed to step 2. Step 2 – Install Golang on CentOS 7 / RHEL 7 Use the link shared to install Go on CentOS 7 / RHEL 7: Install Go (Golang) on CentOS 7 / RHEL 7 Checking version of Go after a successful installation: $ go version go version go1.19 linux/amd64 Step 3 – Install runc and conmon Conmon is used to monitor OCI Runtimes and the package is expected installed on the system. The installation can be done using commands shared below. cd ~ git clone https://github.com/containers/conmon cd conmon export GOCACHE="$(mktemp -d)" make sudo make podman cd .. Check the version after the installation. $ conmon --version conmon version 2.0.8 commit: f85c8b1ce77b73bcd48b2d802396321217008762 Perform the same build for runc package. git clone https://github.com/opencontainers/runc.git $GOPATH/src/github.com/opencontainers/runc cd $GOPATH/src/github.com/opencontainers/runc make BUILDTAGS="selinux seccomp" sudo cp runc /usr/bin/runc cd ~/ Use –version command option to check the version. $ runc --version runc version 1.1.0+dev commit: v1.1.0-276-gbc13e33 spec: 1.0.2-dev go: go1.19

libseccomp: 2.3.1 Step 4 – Setup CNI networking for Podman Create /etc/containers directory used to store CNI network configuration files. sudo mkdir -p /etc/containers Download configuration samples and place created directory: sudo curl -L -o /etc/containers/registries.conf https://src.fedoraproject.org/rpms/containers-common/raw/main/f/registries.conf sudo curl -L -o /etc/containers/policy.json https://src.fedoraproject.org/rpms/containers-common/raw/main/f/default-policy.json Step 5 – Install Podman 4.x on CentOS 7 / RHEL 7 Install wget command line utility package. sudo yum -y install wget Download latest release of Podman source code from Github repository. TAG=4.1.1 rm -rf podman* wget https://github.com/containers/podman/archive/refs/tags/v$TAG.tar.gz Extract downloaded file using tar command: tar xvf v$TAG.tar.gz Navigate to podman directory and begin the build process. cd podman*/ make BUILDTAGS="selinux seccomp" sudo make install PREFIX=/usr If you encounter an error below during build: gcc errors for preamble: In file included from vendor/github.com/proglottis/gpgme/data.go:6:0: ./go_gpgme.h:15:1: error: unknown type name 'gpgme_off_t' extern gpgme_off_t gogpgme_data_seek(gpgme_data_t dh, gpgme_off_t offset, int whence); ^ ./go_gpgme.h:15:55: error: unknown type name 'gpgme_off_t' extern gpgme_off_t gogpgme_data_seek(gpgme_data_t dh, gpgme_off_t offset, int whence); ^ make: *** [bin/podman] Error 2 The issue is captured in Podman 4 bug issues page. Recommended quick fix is to update pgpme package. sudo yum remove gpgme-devel -y sudo yum -y install https://cbs.centos.org/kojifiles/packages/gpgme/1.7.1/0.el7.centos.1/x86_64/gpgme-1.7.1-0.el7.centos.1.x86_64.rpm sudo yum -y install https://cbs.centos.org/kojifiles/packages/gpgme/1.7.1/0.el7.centos.1/x86_64/gpgme-devel-1.7.1-0.el7.centos.1.x86_64.rpm After update retry your build. make BUILDTAGS="selinux seccomp" sudo make install PREFIX=/usr List of available build tags, feature and dependency: Build Tag Feature Dependency apparmor apparmor support libapparmor exclude_graphdriver_btrfs exclude btrfs libbtrfs exclude_graphdriver_devicemapper exclude device-mapper libdm libdm_no_deferred_remove exclude deferred removal in libdm libdm seccomp syscall filtering libseccomp selinux selinux process and mount labeling systemd journald logging libsystemd Add comment to override_kernel_checkconfiguration line. sudo sed -ie 's/override_kernel_check/#override_kernel_check/g' /etc/containers/storage.conf You can check the version of Podman 3 installed on CentOS 7 / RHEL 7 after the build. $ podman version Client: Podman Engine Version: 4.1.1 API Version: 4.1.1 Go Version: go1.19 Built: Mon Jul 11 11:30:09 2022 OS/Arch: linux/amd64 Let’s test image download using podman pull command: $ podman pull docker.io/library/alpine:latest Trying to pull docker.io/library/alpine:latest... Getting image source signatures Copying blob 2408cc74d12b done Copying config e66264b987 done Writing manifest to image destination Storing signatures e66264b98777e12192600bf9b4d663655c98a090072e1bab49e233d7531d1294 You can also run Docker Hello World container to confirm this works: $ podman run docker.io/library/hello-world Trying to pull docker.io/library/hello-world:latest... Getting image source signatures Copying blob 2db29710123e done Copying config feb5d9fea6 done Writing manifest to image destination Storing signatures Hello from Docker! This message shows that your installation appears to be working correctly. To generate this message, Docker took the following steps: 1. The Docker client contacted the Docker daemon. 2. The Docker daemon pulled the "hello-world" image from the Docker Hub. (amd64) 3. The Docker daemon created a new container from that image which runs the

executable that produces the output you are currently reading. 4. The Docker daemon streamed that output to the Docker client, which sent it to your terminal. To try something more ambitious, you can run an Ubuntu container with: $ docker run -it ubuntu bash Share images, automate workflows, and more with a free Docker ID: https://hub.docker.com/ For more examples and ideas, visit: https://docs.docker.com/get-started/ This is a reference guide on using Podman: Run Docker Containers using Podman and Libpod

[foxutech]

Manage Linux logs with Systemd

Manage Linux logs with Systemd

Systemd is a system and service manager for Linux. It’s become the de facto system management daemon in various Linux distributions in recent years. Systemd was first introduced in Fedora. Other distributions like Arch Linux, openSUSE, or CoreOS have already made it part of their operating systems. Red Hat Enterprise Linux (RHEL) and its downstream distros like CentOS started to use systemd…

[paradisetechsoftsolutions]

Beginner’s Guide To Setup Kubernetes

Steps to install Kubernetes Cluster

Requirements

The major requirements are stated below regarding the setup process.

Master: 2 GB RAM 2 Cores of CPU Slave/ Node: 1 GB RAM 1 Core of CPU

1.Install Kubernetes

The below steps mentioned to be executed on both the master and node machines. Let’s call the master as ‘kmaster‘ and node as ‘knode‘.

1.1 Change to root:

Here, the changing root has been applied because the sudo provides permission to set up Kubernetes, and to avoid the permission process we have changed the root.‌

$ sudo su

# apt-get update

This command used to update a system.

1.2 Turn Off Swap Space:

Kubernetes doesn't support "swap". So we have to apply the below command to turn off the swap space.

# swapoff -a

1.3 Fstab action

After that, you need to open the ‘fstab’ file and comment out the line which has mention of swap partition.

# nano /etc/fstab

Press ‘Ctrl+X’, after that press ‘Y’ and then press ‘Enter’ to Save the file.

1.4 Update The Hostnames

To change the hostname of both machines, run the below command to open the file and subsequently rename the master machine to ‘kmaster’ and your node machine to ‘knode’.

# nano /etc/hostname

Press ‘Ctrl+X’, after that press ‘Y’ and then press ‘Enter’ to Save the file.

1.5 Update The Hosts File With IPs Of Master & Node

Run the following command on both machines to note the IP addresses of each.

# ifconfig

Now go to the ‘hosts’ file by moving over the both master and node and add an Entry by just specifying their respective IP addresses along with their names i.e. ‘kmaster’ and ‘knode’.

# nano /etc/hosts

Press ‘Ctrl+X’, after that press ‘Y’ and then press ‘Enter’ to Save the file.

1.6 Setting Static IP Addresses

We will make the IP addresses used as above, static for the VMs. We can do, by just modifying/changing the network interfaces file. Then, run the following command to open the file:

# nano /etc/network/interfaces

Now enter the following lines in the file.

auto enp0s8 iface enp0s8 inet static address

Press ‘Ctrl+X’, after that press ‘Y’ and then press ‘Enter’ to Save the file.

After this, restart your machine.

1.7 Install Open SSH-Server

Now we have to install openshh-server. Run the following command:

# sudo apt-get install openssh-server

2. Install Docker

Now we need to install Docker as docker images will be utilized for managing the containers in the cluster. Run with the following commands:

# sudo su # apt-get update # apt-get install -y docker.io

We’ve just explained about how to docker in your own system instead the process of how to add a $user in a docker or how to install docker-compose, for the basics of kubernetes you can follow by just tapping over this link:

3. Install kubeadm, Kubelet And Kubectl

To move further, we’ve to Install these 3 essential components for just setting up the environment of Kubernetes: kubeadm, kubectl, and kubelet.

Run the following commands before installing the Kubernetes environment.

# apt-get update && apt-get install -y apt-transport-https curl # curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - # cat <<EOF >/etc/apt/sources.list.d/kubernetes.list deb http://apt.kubernetes.io/ kubernetes-xenial main EOF # apt-get update

Kubelet is the lowest level component in Kubernetes. It’s reliable for what’s running on an individual or specific machine.

Kubeadm is used for administrating the Kubernetes cluster.

Kubectl is used for controlling the configurations on various nodes inside the cluster.

# apt-get install -y kubelet kubeadm kubectl

3.1 Updating Kubernetes Configuration

Next, we will change the configuration file of Kubernetes. Run the following command:

#nano /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

This will open a text editor, enter the following line after the last “Environment Variable”:

Environment="cgroup-driver=systemd/cgroup-driver=cgroupfs"

Press ‘Ctrl+X’, after that press ‘Y’ and then press ‘Enter’ to Save the file.

4. Steps Only For Kubernetes Master VM (kmaster)

All the required packages were installed on both servers till now. But, the further steps will work upon the Master Node only. Now, run the following command to initialize the Kubernetes Master.

4.1 Initialize Kubernetes Master with ‘kubeadm init’

Run the beneath command to  initialize and setup kubernetes master.

# kubeadm init (or) # kubeadm init --apiserver-advertise-address=<ip-address-of-kmaster-vm> --pod-network-cidr=192.168.0.0/16 # kubeadm init --apiserver-advertise-address 192.168.1.206 --pod-network-cidr=172.16.0.0/16

In the selected part 1, when we initialize Kubeadm with the command then it will show you the kubernetes control-panel has initialized successfully. The three commands as shown in the images’ part 1 should be run to create .kube folder.

As mentioned before, run the commands from the above output as a non-root user

$ mkdir -p $HOME/.kube $ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config $ sudo chown $(id -u):$(id -g) $HOME/.kube/config

In the selected part 2, signifies about the “kubeadm join token”. The kubeadm token need to store somewhere in notepad and wherever you want to. After storing, you need to run that specific key token in a node terminal so that it can maintain the communication between the master and node.

You will notice from the previous command, that all the pods are running except one: ‘kube-dns’. For resolving this we will install a pod network. To install the CALICO pod network, run the following command:

$ kubectl apply -f https://docs.projectcalico.org/v3.0/getting-started/kubernetes/installation/hosted/kubeadm/1.7/calico.yaml

Install network add-on to enable the communication between the pods only on master nodes. Flannel is a network fabric for the containers, that are designed for the kubernetes.  

$ kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

To verify, if kubectl is working or not, run the following command.s

$ kubectl get pods -o wide --all-namespaces

use "kubectl get nodes" command to ensure the kubernetes master node status is ready.

$ kubectl get nodes

4.2 To reset kubernetes

Now, if you are done with the process of initiating the command and requiring a fresh start, then you can make changes by just following the below command.

$ kubeadm reset

5. Steps For Only Kubernetes Node VM (knode)

For trial purpose, we can create nodes in the same system with the help of virtual machine.

Prerequisites

1.3GHz or faster 64-bit processor 2 GB RAM minimum/ 4GB RAM or more recommended

install vmware workstation player on ubuntu

5.1 Install required packages

$ sudo apt update $ sudo apt install build-essential</strong> $ sudo apt install linux-headers-$(uname -r)

5.2 Download vmware workstation player

$ wget https://www.vmware.com/go/getplayer-linux

Once the download is completed make the installation file executable using the following command:

$ chmod +x getplayer-linux

5.3 install vmware workstation player

Start the Installation wizard by typing:

$ sudo ./getplayer-linux

1. Just accept the terms and conditions in the license agreement and click on the Next button.

2. Next, you will be asked whether you like to check for product updates on startup. Make your selection and click on the Next button.

3. VMware’s Customer Experience Improvement Program (“CEIP”) helps VMware to improve their products and services by sending anonymous system data and usage information to VMware. If you prefer not to participate in the program select No and click on the Next button

4. In the next step , if you don’t have a license key, vacate the field empty and click on the next button.

5. Next, you will see the following page informing you that the VMware Workstation Player is ready to be installed. Click on the Install button.

6. Start VMware Workstation Player

Create a new virtual machine

Open terminal in virtual system and follow the step to create user (knode) and enter command to make connection between master and node.

$ sudo su

Now we are in the ‘knode terminal’ and we need to run kubeadm init. token key in this terminal as we have described above to save the specific key so that it make connection between master( kmaster) and node(knode).

# kubeadm join 192.168.1.206:6443 --token 02p54b.p8oe045cpj3zmz2b --discovery-token-ca-cert-hash sha256:50ba20a59c9f8bc0559d4635f1ac6bb480230e173a0c08b338372d8b81fcd061

once worker node is joined with kubernetes master, then verify the list of nodes within the kubernetes cluster.

$ kubectl get nodes

we have successfully configured the kubernetes cluster.

kubernetes master and worker node is ready to deploy the application.

Bottom Line

Now that we have explained about kubernetes setup, and further we will move onto something more technical with the other parts of this kubernetes series. Our next tutorial would explain to you how to make a connection with dashboard. Till then enjoy learning and try something new.

[for-the-user]

docker cheatsheet

Ubuntu (old using upstart ) - /var/log/upstart/docker.log Ubuntu (new using systemd ) - journalctl -u docker.service Boot2Docker - /var/log/docker.log Debian GNU/Linux - /var/log/daemon.log CentOS - /var/log/daemon.log | grep docker CoreOS - journalctl -u docker.service Fedora - journalctl -u docker.service Red Hat Enterprise Linux Server - /var/log/messages | grep docker OpenSuSE - journalctl -u docker.service OSX - ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/log/docker.log

Run a container with a loop so you can enter it

$ docker run -d --name angular_app angular_app /bin/bash -c "while true; do echo blah; sleep 1; done" $ docker exec -it angular_app /bin/bash

Access files built on a container that stops after it finishes building

$ docker run -i --name something -v /dir:/dir something /bin/bash -c "npm i" $ docker commit something something-built $ docker run -i --name something-built -v /dir:/dir something-built /bin/bash -c "npm t"

Remove all exited containers

$ docker container prune

Remove all old images

$ docker image prune -af

Check whether a container is running or not

$ docker inspect --format {{.State.Running}} something_container

Check container stats

$ docker stats something_container --format {{.MemPerc}}{{.CPUPerc}} --no-stream

Save an image as a tarball (in case you have it locally on one computer, and you can't pull it on another computer for some reason) and transfer it to another computer.

1st computer: $ docker save -o /tmp/kubelet.tgz kubelet $ scp /tmp/kubelet.tgz 123.45.67.89:/tmp/ 2nd computer: $ docker load -i /tmp/kubelet.tgz

[animacionesadultos]

systemd at the Core of the OS (CoreOS Fest 2015)

systemd at the Core of the OS (CoreOS Fest 2015)

http://showanimaciones.com/systemd-at-the-core-of-the-os-coreos-fest-2015/ ANIMACIONES PARA CUMPLEAÑOS EN: showanimaciones.com Lennart Poettering, Creator of systemd, Red Hat talks about systemd at the core of the OS. source

ANIMACIONES PARA CUMPLEAÑOS EN: showanimaciones.com WHATSAPP 011 3187-0574

//pagead2.googlesyndication.com/pag…

[andrey-v-maksimov]

CoreOS: кластер в Облаке КРОК

CoreOS: кластер в Облаке КРОК

Если вы активно используете контейнеры в своей повседневной жизни, вам однозначно стоит взглянуть на CoreOS. Эта ОС работает абсолютно во всех самых распространенных облаках (EC2, Rackspace, GCE, Облаке КРОК), платформах виртуализации (Vagrant, VMware, OpenStack, QEMU / KVM), а также голом железе (PXE, iPXE, ISO, Installer). С помощью любого из этих руководств всего за несколько минут у вас…

[dummdida]

Virtual Machines in Kubernetes? How and what makes sense?

Happy new year.

I stopped by saying that Kubernetes can run containers on a cluster. This implies that it can perform some cluster operations (i.e. scheduling). And the question is if the cluster logic plus some virtualization logic can actually provide us virtualization functionality as we know it from oVirt.

Can it?

Maybe. At least there are a few approaches which already tried to run VMs within or on-top of Kubernetes.

Note. I'm happy to get input on clarifications for the following implementations.

Hyper created a fork to launch the container runtimes inside a VM:

docker-proxy | v [VM | docker-runtime] | + container + container :

runV is also from hyper. It is a OCI compatible container runtime. But instead of launching a container, this runtime will really launch a VM (libvirtd, qemu, …) with a given kernel, initrd and a given docker (or OCI) image.

This is pretty straight forward, thanks to the OCI standard.

frakti is actually a component implementing Kubernetes CRI (container runtime interface), and it can be used to run VM-isolated-containers in Kubernetes by using Hyper above.

rkt is actually a container runtime, but it supports to be run inside of KVM. To me this looks similar to runv, as a a VM is used for isolation purpose around a pod (not a single container).

host OS └─ rkt └─ hypervisor └─ kernel └─ systemd └─ chroot └─ user-app1

ClearContainers seem to be also much like runv and the alternative stage1 for rkt.

RancherVM is using a different approach - The VM is run inside the contianer, instead of wrapping it (like the approaches above). This means the container contains the VM runtime (qemu, libirtd, …). The VM can actually be directly adressed, because it's an explicit component.

host OS └─ docker └─ container └─ VM

This brings me to the wrap-up. Most of the solutions above use VMs as an isolation mechanism to containers. This happens transparently - as far as I can tell the VM is not directly exposed to higher levels, an dcan thus not be directly adressed in the sense of configured (i.e. adding a second display).

Except for the RancherVM solution where the VM is running inside a container. Her ethe VM is layered on-top, and is basically not hidden in the stack. By default the VM is inheriting stuff form the pod (i.e. networking, which is pretty incely solved), but it would also allow to do more with the VM.

So what is the take away? So, so, I would say. Looks like there is at least interest to somehow get VMs working for the one or the other use-case in the Kubernetes context. In most cases the Vm was hidden in the stack - this currently prevents to directly access and modify the VM, and it actually could imply that the VM is handled like a pod. Which actually means that the assumptions you have on a container will also apply to the VM. I.e. it's stateless, it can be killed, and reinstantiated. (This statement is pretty rough and hides a lot of details).

VM The issue is that we do care about VMs in oVirt, and that we love modifying them - like adding a second display, migrating them, tuning boot order and other fancy stuff. RancherVM looks to be going into a direction where we could tnue, but the others don't seem to help here.

Cluster Another question is: All the implementations above cared about running a VM, but oVirt is also caring about more, it's caring about cluster tasks - i.e. live migration, host fencing. And if the cluster tasks are on Kubernetes shoulders, then the question is: Does Kubernetes care about them as much as oVirt does? Maybe.

Conceptually Where do VMs belong? Above implementations hide the VM details (except RancherVM) - one reaosn is that Kubernetes does not care about this. Kubernetes does not have a concept for VMs- not for isolation and not as an explicit entity. And the questoin is: Should Kubernetes care? Kubernetes is great on Containers - and VMs (in the oVirt sense) are so much more. Is it worth to push all the needed knowledge into Kubernetes? And would this actually see acceptance from Kubernetes itself?

I tend to say No. The strength of Kubernetes is that it does one thing, and it does it well. Why should it get so bloated to expose all VM details?

But maybe it can learn to run VMs, and knows enough about them, to provifde a mechanism to pass through additional configuration to fine tune a VM.

Many open questions. But also a little more knowledge - and a post that got a little long.

[sysnotes]

Messy Notes on CoreOS MatchBox

CoreOS Matchbox Setup Notes.

dnsmasq

interface=eth1 bind-interfaces dhcp-range=10.16.0.10,10.16.0.99,255.255.255.0,24h dhcp-option=option:router,10.16.0.1 dhcp-boot=pxelinux.0 enable-tftp tftp-root=/srv/tftp dhcp-match=gpxe,175 # gPXE sends a 175 option. dhcp-boot=net:#gpxe,undionly.kpxe dhcp-boot=http://10.16.0.1/boot.ipxe address=/node1/10.16.0.101 address=/node2/10.16.0.102 address=/node3/10.16.0.103

profiles json:

{ "id": "bootkube", "name": "bootkube", "cloud_id": "", "ignition_id": "bootkube.yml", "generic_id": "", "boot": { "kernel": "/assets/vmlinuz", "initrd": ["/assets/cpio.gz"], "args": [ "root=/dev/vda1", "coreos.config.url=http://10.16.0.1/ignition?uuid=${uuid}&mac=${mac:hexhyp}", "coreos.first_boot=yes", "coreos.autologin" ] } }

groups json:

{ "name": "bootkube1", "profile": "bootkube", "selector": { "mac": "52:54:00:90:c3:6e" }, "metadata": { "domain_name": "node1", "ADVERTISE_IP": "10.16.0.101", "SERVER_IP": "10.16.0.1", "etcd_initial_cluster": "node1=http://10.16.0.101:2380,node2=http://10.16.0.102:2380,node3=http://10.16.0.103:2380", "etcd_name": "node1", "k8s_dns_service_ip": "10.3.0.10" } }

ignitons yml:

passwd: users: - name: core ssh_authorized_keys: - ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBFTHetURpsQ2fkYXhAGMPDPArd4ubKfwRFvtcXtcp/PAnO8LFg4xQCtUbpgj4KoLYZEXblz/woXlm4coXT3C9Sg= networkd: units: - name: 005-eth0.network contents: | [Match] Name=eth0 [Network] DNS={{.SERVER_IP}} Address={{.ADVERTISE_IP}}/24 Gateway={{.SERVER_IP}} etcd: version: 3.3.9 name: {{.etcd_name}} advertise_client_urls: http://{{.ADVERTISE_IP}}:2379 initial_advertise_peer_urls: http://{{.ADVERTISE_IP}}:2380 listen_client_urls: http://0.0.0.0:2379 listen_peer_urls: http://0.0.0.0:2380 initial_cluster: {{.etcd_initial_cluster}} #ca_file: /etc/ssl/certs/etcd/etcd/server-ca.crt #cert_file: /etc/ssl/certs/etcd/etcd/server.crt #key_file: /etc/ssl/certs/etcd/etcd/server.key #peer_ca_file: /etc/ssl/certs/etcd/etcd/peer-ca.crt #peer_cert_file: /etc/ssl/certs/etcd/etcd/peer.crt #peer_key_file: /etc/ssl/certs/etcd/etcd/peer.key systemd: units: - name: update-engine.service mask: true - name: locksmithd.service mask: true - name: etcd-member.service enable: true - name: docker.service enable: true - name: rngd.service enable: true contents: | [Unit] Description=Hardware RNG Entropy Gatherer Daemon [Service] ExecStart=/usr/sbin/rngd -f -r /dev/urandom [Install] WantedBy=multi-user.target - name: get-assets.service enable: true contents: | [Unit] Description=Get Bootkube assets [Service] Type=oneshot ExecStart=/usr/bin/wget --cut-dirs=1 -R "index.html*" --recursive -nH http://{{.SERVER_IP}}/assets -P /opt/bootkube/assets #ExecStartPre=/usr/bin/wget --cut-dirs=2 -R "index.html*" --recursive -nH http://10.16.0.1/assets/tls -P /etc/ssl/certs/etcd #ExecStartPre=/usr/bin/chown etcd:etcd -R /etc/ssl/etcd #ExecStartPre=/usr/bin/find /etc/ssl/etcd -type f -exec chmod 600 {} \; [Install] WantedBy=multi-user.target - name: kubelet.service enable: true contents: | [Unit] Description=Kubelet via Hyperkube ACI [Service] EnvironmentFile=/etc/kubernetes/kubelet.env Environment="RKT_RUN_ARGS=--uuid-file-save=/var/cache/kubelet-pod.uuid \ --volume=resolv,kind=host,source=/etc/resolv.conf \ --mount volume=resolv,target=/etc/resolv.conf \ --volume var-lib-cni,kind=host,source=/var/lib/cni \ --mount volume=var-lib-cni,target=/var/lib/cni \ --volume opt-cni-bin,kind=host,source=/opt/cni/bin \ --mount volume=opt-cni-bin,target=/opt/cni/bin \ --volume var-log,kind=host,source=/var/log \ --mount volume=var-log,target=/var/log \ --insecure-options=image" ExecStartPre=/bin/mkdir -p /opt/cni/bin ExecStartPre=/bin/mkdir -p /etc/kubernetes/manifests ExecStartPre=/bin/mkdir -p /etc/kubernetes/cni/net.d ExecStartPre=/bin/mkdir -p /etc/kubernetes/checkpoint-secrets ExecStartPre=/bin/mkdir -p /etc/kubernetes/inactive-manifests ExecStartPre=/bin/mkdir -p /var/lib/cni ExecStartPre=/usr/bin/bash -c "grep 'certificate-authority-data' /etc/kubernetes/kubeconfig | awk '{print $2}' | base64 -d > /etc/kubernetes/ca.crt" ExecStartPre=-/usr/bin/rkt rm --uuid-file=/var/cache/kubelet-pod.uuid ExecStart=/usr/lib/coreos/kubelet-wrapper \ --anonymous-auth=false \ --cluster-dns={{.k8s_dns_service_ip}} \ --cluster-domain=cluster.local \ --client-ca-file=/etc/kubernetes/ca.crt \ --pod-manifest-path=/etc/kubernetes/manifests \ --feature-gates=AttachVolumeLimit=false \ --cni-conf-dir=/etc/kubernetes/cni/net.d \ --exit-on-lock-contention \ --kubeconfig=/etc/kubernetes/kubeconfig \ --lock-file=/var/run/lock/kubelet.lock \ --network-plugin=cni \ --node-labels=node-role.kubernetes.io/master \ --register-with-taints=node-role.kubernetes.io/master=:NoSchedule ExecStop=-/usr/bin/rkt stop --uuid-file=/var/cache/kubelet-pod.uuid Restart=always RestartSec=10 [Install] WantedBy=multi-user.target - name: bootkube.service #enable: true contents: | [Unit] Description=Bootstrap a Kubernetes control plane with a temp api-server [Service] Type=simple WorkingDirectory=/opt/bootkube ExecStart=/opt/bootkube/bootkube-start [Install] WantedBy=multi-user.target storage: disks: - device: /dev/vda wipe_table: true partitions: - label: ROOT filesystems: - name: root mount: device: "/dev/vda1" format: "ext4" create: force: true options: - "-LROOT" files: - path: /etc/kubernetes/kubeconfig filesystem: root mode: 0644 contents: remote: url: http://{{.SERVER_IP}}/assets/auth/kubeconfig - path: /etc/kubernetes/kubelet.env filesystem: root mode: 0644 contents: inline: | KUBELET_IMAGE_URL=docker://gcr.io/google_containers/hyperkube KUBELET_IMAGE_TAG=v1.12.1 - path: /etc/hostname filesystem: root mode: 0644 contents: inline: {{.domain_name}} - path: /etc/sysctl.d/max-user-watches.conf filesystem: root contents: inline: | fs.inotify.max_user_watches=16184 - path: /opt/bootkube/bootkube-start filesystem: root mode: 0544 contents: inline: | #!/bin/bash set -e BOOTKUBE_ACI="${BOOTKUBE_ACI:-quay.io/coreos/bootkube}" BOOTKUBE_VERSION="${BOOTKUBE_VERSION:-v0.14.0}" #BOOTKUBE_VERSION="${BOOTKUBE_VERSION:-v0.9.1}" BOOTKUBE_ASSETS="${BOOTKUBE_ASSETS:-/opt/bootkube/assets}" exec /usr/bin/rkt run \ --trust-keys-from-https \ --volume assets,kind=host,source=$BOOTKUBE_ASSETS \ --mount volume=assets,target=/assets \ --volume bootstrap,kind=host,source=/etc/kubernetes \ --mount volume=bootstrap,target=/etc/kubernetes \ $RKT_OPTS \ ${BOOTKUBE_ACI}:${BOOTKUBE_VERSION} \ --net=host \ --dns=host \ --exec=/bootkube -- start --asset-dir=/assets "$@"

bootkube render --asset-dir=bootkube-assets --api-servers=https://10.16.0.101:6443,https://10.16.0.102:6443,https://10.16.0.103:6443 --api-server-alt-names=IP=10.16.0.101,IP=10.16.0.102,IP=10.16.0.103 --etcd-servers=http://10.16.0.101:2379,http://10.16.0.102:2379,http://10.16.0.103:2379 --network-provider experimental-canal

[itbeatsbookmarks]

(Via: Hacker News)

Or why don’t free and top work in a Linux container?

Lately at Heroku, we have been trying to find the best way to expose memory usage and limits inside Linux containers. It would be easy to do it in a vendor-specific way: most container specific metrics are available at the cgroup filesystem via /path/to/cgroup/memory.stat, /path/to/cgroup/memory.usage_in_bytes, /path/to/cgroup/memory.limit_in_bytes and others.

An implementation of Linux containers could easily inject one or more of those files inside containers. Here is an hypothetical example of what Heroku, Docker and others could do:

# create a new dyno (container): $ heroku run bash # then, inside the dyno: (dyno) $ cat /sys/fs/cgroup/memory/memory.stat cache 15582273536 rss 2308546560 mapped_file 275681280 swap 94928896 pgpgin 30203686979 pgpgout 30199319103 # ...

/sys/fs/cgroup/ is the recommended location for cgroup hierarchies, but it is not a standard. If a tool or library is trying to read from it, and be portable across multiple container implementations, it would need to discover the location first by parsing /proc/self/cgroup and /proc/self/mountinfo. Further, /sys/fs/cgroup is just an umbrella for all cgroup hierarchies, there is no recommendation or standard for my own cgroup location. Thinking about it, /sys/fs/cgroup/self would not be a bad idea.

If we decide to go down that path, I would personally prefer to work with the rest of the Linux containers community first and come up with a standard.

I wish it were that simple.

The problem

Most of the Linux tools providing system resource metrics were created before cgroups even existed (e.g.: free and top, both from procps). They usually read memory metrics from the proc filesystem: /proc/meminfo, /proc/vmstat, /proc/PID/smaps and others.

Unfortunately /proc/meminfo, /proc/vmstat and friends are not containerized. Meaning that they are not cgroup-aware. They will always display memory numbers from the host system (physical or virtual machine) as a whole, which is useless for modern Linux containers (Heroku, Docker, etc.). Processes inside a container can not rely on free, top and others to determine how much memory they have to work with; they are subject to limits imposed by their cgroups and can’t use all the memory available in the host system.

This causes a lot of confusion for users of Linux containers. Why does free say there is 32GB free memory, when the container only allows 512MB to be used?

With the popularization of linux container technologies – Heroku, Docker, LXC (version 1.0 was recently released), CoreOS, lmctfy, systemd and friends – more and more people will face the same problem. It is time to start fixing it.

Why is this important?

Visibility into memory usage is very important. It allows people running applications inside containers to optimize their code and troubleshoot problems: memory leaks, swap space usage, etc.

Some time ago, we shipped log-runtime-metrics at Heroku, as an experimental labs feature. It is not a portable solution though, and does not expose the information inside containers, so that monitoring agents could read it. To make things worse, most of the monitoring agents out there (e.g.: NewRelic?1) rely on information provided by free, /proc/meminfo, etc. That is plain broken inside Linux containers.

On top of that, more and more people have been trying to maximize resource usage inside containers, usually by auto-scaling the number of workers, processes or threads running inside them. This is usually a function of how much memory is available (and/or free) inside the container, and for that do be done programmatically, the information needs to be accessible from inside the container.

More about /proc

In case you wondered, none of the files provided by the cgroup filesystem (/sys/fs/cgroup/memory/memory.*) can be used as a drop-in replacement (i.e.: bind mounted on top of) for /proc/meminfo, or /proc/vmstat. They have different formats and use slightly different names for each metric. Why memory.stat and friends decided to use a format different from what was already being used at /proc/meminfo is beyond my comprehension.

Some of the contents of a /proc filesystem are properly containerized, like the /proc/PID/* and /proc/net/* namespaces, but not all of them. Unfortunately, /proc in general is considered to be a mess. From the excellent “Creating Linux virtual filesystems” article on LWN:

Linus and numerous other kernel developers dislike the ioctl() system call, seeing it as an uncontrolled way of adding new system calls to the kernel. Putting new files into /proc is also discouraged, since that area is seen as being a bit of a mess. Developers who populate their code with ioctl() implementations or /proc files are often encouraged to create a standalone virtual filesystem instead.

I went ahead and started experimenting with that: procg is an alternative proc filesystem that can be mounted inside linux containers. It replaces /proc/meminfo with a version that reads cgroup specific information. My goal was for it to be a drop-in replacement for proc, without requiring any patches to the Linux kernel. Unfortunately, I later found that it was not possible, because none of the functions to read memory statistics from a cgroup (linux/memcontrol.h and mm/memcontrol.c) are public in the kernel. I hope to continue this discussion on LKML soon.

Others have tried similar things modifying the proc filesystem directly, but that is unlikely to be merged to the mainstream kernel if it affects all users of the proc filesystem. It would either need to be a custom filesystem (like procg) or a custom mount option to proc. E.g.:

mount -t proc -o meminfo-from-cgroup none /path/to/container/proc

FUSE

There is also a group of kernel developers advocating that this would be better served by something outside of the kernel, in userspace, making /proc/meminfo be a virtual file that collects information elsewhere and formats it appropriately.

FUSE can be used to implement a filesystem in userspace to do just that. Libvirt went down that path with its libvirt-lxc driver. There were attempts to integrate a FUSE version of /proc/meminfo into LXC too.

Even though there is a very nice implementation of FUSE in pure Go, and that I am excited with the idea to contribute a plugin/patch to Docker using it, at Heroku we (myself included) have a lot of resistance against using FUSE in production.

This is mainly due to bad past experiences with FUSE filesystems (sshfs, s3fs) and the increased surface area for attacks. My research so far has revealed that the situation may be much better nowadays, and I would even be willing to give it a try if there were not other problems with using fuse to replace the proc filesystem.

I am also not comfortable with making my containers dependent on an userspace daemon that serves FUSE requests. What happens when that daemon crashes? All containers in the box are probably left without access to their /proc/meminfo. Either that, or having to run a different daemon per container. Hundreds of containers in a box would require hundreds of such daemons. Ugh.

/proc is not the only issue: sysinfo

Even if we could find a solution to containerize /proc/meminfo with which everyone is happy, it would not be enough.

Linux also provides the sysinfo(2) syscall, which returns information about system resources (e.g. memory). As with /proc/meminfo, it is not containerized: it always returns metrics for the box as a whole.

I was surprised while testing my proc replacement (procg) that it did not work with Busybox. Later, I discovered that the Busybox’s implementation of free does not use /proc/meminfo. Guess what? It uses sysinfo(2). What else out there could also be using sysinfo(2) and be broken inside containers?

ulimit, setrlimit

On top of cgroup limits, Linux processes are also subject to resource limits applied to them individually, via setrlimit(2).

Both cgroup limits and rlimit apply when memory is being allocated by a process.

systemd

Soon, cgroups are going to be managed by systemd. All operations on cgroups are going to be done through API calls to systemd, over DBUS (or a shared library).

That makes me think that systemd could also expose a consistent API for processes to query their available memory.

But until then…

Solution?

Some kernel developers (and I am starting to agree with them) believe that the best option is an userspace library that processes can use to query their memory usage and available memory.

libmymem would do all the hard work of figuring out where to pull numbers from (/proc vs. cgroup vs. getrlimit(2) vs. systemd, etc.). I am considering starting one. New code could easily benefit from it, but it is unlikely that all existing tools (free, top, etc.) will just switch to it. For now, we might need to encourage people to stop using those tools inside containers.

I hope my unfortunate realization – figuring out how much memory you can use inside a container is harder than it should be – helps people better understand the problem. Please leave a comment below and let me know what you think.

[cloudshiftco]

How To Create a Cronjob on CoreOS ?

https://cloudshift.co/uncategorized/how-to-create-a-cronjob-on-coreos/

How To Create a Cronjob on CoreOS ?

Nowadays, cause of the features of CoreOS we have started to use it on our environments.

It is even more popular after the Red Hat has purchased it.  ıt is a little bit different operating system also known as immutable operating system. It has no package manager and cron utility.  So I ll explain other details on another post but today I am going to explain the details of that how can we enable cronjob on CoreOs .

As I mentioned there is no cron utility on CoreOS.  So only thing that we can do is to configure the systemd services.

First of all let s assume I have a script which needs to be executed everytime. So only one systemd configuration s enough to succeed.

# vi /scripts/executedbystsemd.sh !#/bin/bash echo "This command is executed by systemd"

  # vi /etc/systemd/system/runningeverytime.service [Unit] Description=This service is running everytime [Service] Type=oneshot ExecStart=bash /scripts/executedbysystemd.sh [Install] WantedBy=multi-user.target

[computingpostcom]

In most cases you will not require SSH access to your OpenShift cluster nodes for regular administration tasks because OpenShift 4 provides the oc debug command which can be used for shell access. If you still prefer SSH access to the cluster nodes for day 2 operations, SSH keys used during deployment have to be used. For lost Private & Public SSH key pairs, there is a possibility to update OpenShift 4.x Cluster SSH Keys after installation provided you have administrative oc management. This also applies to configuration of ssh keys post-installation if the OpenShift cluster was installed without ssh keys. We will see how you update ssh keys for master, infra and worker machines in your OpenShift 4.x cluster. The update of the SSH keys in the cluster is performed by modifying (or creating) the proper MachineConfig objects on the cluster. OpenShift 4 is an operator-focused platform, and the Machine Config operator extends that to the operating system itself, managing updates and configuration changes to essentially everything between the kernel and kubelet. By default, RHCOS contains a single user named core (derived in spirit from CoreOS Container Linux) with optional SSH keys specified at install time. Update OpenShift 4.x SSH keys after cluster Setup By default, there are two MachineConfig objects that handles management of SSH keys: 99-worker-ssh – This is used for worker nodes 99-master-ssh – For Master nodes in the cluster If SSH keys are specified at the time of cluster installation they are propagated to above MachineConfig objects. Update OpenShift Master nodes SSH Keys If earlier cluster installation was done with SSH keys, download current SSH MachineConfig object for the Master nodes $ oc get mc 99-master-ssh -o yaml > 99-master-ssh.yml This should be done from bastion server with admin level cluster access. Once the file is downloaded, edit it with the desired keys like. For cluster created without SSH keys create a new file 99-master-ssh.yml: apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: master name: 99-master-ssh spec: config: ignition: config: security: tls: timeouts: version: 2.2.0 networkd: passwd: users: - name: core sshAuthorizedKeys: - ssh-rsa XXXXXXX..... - ssh-rsa YYYYYYY..... storage: systemd: fips: false kernelArguments: null osImageURL: "" Key notes: sshAuthorizedKeys array contains all the valid SSH public keys. Each SSH key at each element. You must be careful with YAML syntax to have a working configuration file. The user: name field should not be updated as core is the only user currently supported in our configuration. Updating the MachineConfig object may drain and reboot all the nodes one by one (as per maxUnavailable setting on MachineConfigPool). Decide if this is okay in your Infrastructure. To update MachineConfig object run the command: $ oc apply -f 99-master-ssh.yml Update OpenShift Worker / Infra nodes SSH Keys The same process applies to Worker nodes MachineConfigPool. Download or create worker ssh configuration. $ oc get mc 99-worker-ssh -o yaml > 99-worker-ssh.yml The configuration is update similar to previous: apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: 99-worker-ssh spec: config: ignition: config: security: tls: timeouts: version: 2.2.0 networkd: passwd: users: - name: core sshAuthorizedKeys: - ssh-rsa XXXXXXX..... - ssh-rsa YYYYYYY..... storage: systemd: fips: false kernelArguments: null osImageURL: "" Once changes are done, apply the file: $ oc apply -f 99-worker-ssh.yml OpenShift Machine Config Operator should start applying the changes shortly.

You can run the following command to see which MachineConfigPools are being updated: oc get mcp You can also get more insight on how the change are being applied in a single node using the command below: export NODE="master-01.example.com" oc -n openshift-machine-config-operator logs -c machine-config-daemon $(oc -n openshift-machine-config-operator get pod -l k8s-app=machine-config-daemon --field-selector spec.nodeName=$NODE -o name) -f Replace master-01.example.com with node name to check. We hope this article enabled you to update SSH keys in your OpenShift 4.x Cluster after installation with or without SSH keys.  

[onforumoftechtk]

What Makes Up a Kubernetes Cluster?

In our initial three portions in this arrangement, we realized what Kubernetes is, the reason it's a decent decision for your datacenter, and how it was slipped from the mystery Google Borg extend. Presently will realize what makes up a Kubernetes bunch.

A Kubernetes bunch is made of an ace hub and an arrangement of specialist hubs. In a creation situation these keep running in a conveyed setup on various hubs. For testing purposes, every one of the segments can keep running on a similar hub (physical or virtual) by utilizing minikube.

Kubernetes has six fundamental parts that frame a working group:

Programming interface server

Scheduler

Controller director

kubelet

kube-intermediary

etcd

Each of these segments can keep running as standard Linux procedures, or they can keep running as Docker containers.The Master Node

The ace hub runs the API server, the scheduler, and the controller supervisor. For instance, on one of the Kubernetes ace hubs that we began on a CoreOS example, we see the accompanying systemd unit documents:

core@master ~ $ systemctl - a | grep kube

kube-apiserver.service stacked dynamic running Kubernetes API Server

kube-controller-manager.service stacked dynamic running Kubernetes Controller Manager

kube-scheduler.service stacked dynamic running Kubernetes Scheduler

The API server uncovered an exceptionally configurable REST interface to the majority of the Kubernetes assets.

The Scheduler's principle duty is to put the compartments on the hub in the bunch as indicated by different approaches, measurements, and asset prerequisites. It is likewise configurable by means of order line banners.

At long last, the Controller Manager is in charge of accommodating the condition of the bunch with the coveted state, as indicated by means of the API. As a result, it is a control circle that performs activities in view of the watched condition of the group and the coveted state.

The ace hub bolsters a multi-ace exceedingly accessible setup. The schedulers and controller supervisors can choose a pioneer, while the API servers can be fronted by a heap balancer.

Laborer Nodes

All the laborer hubs run the kubelet, kube-intermediary, and the Docker motor.

The kubelet communicates with the hidden Docker motor to raise compartments as required. The kube-intermediary is accountable for overseeing system network to the holders.

core@node-1 ~ $ systemctl - a | grep kube

kube-kubelet.service stacked dynamic running Kubernetes Kubelet

kube-proxy.service stacked dynamic running Kubernetes Proxy

core@node-1 ~ $ systemctl - a | grep docker

docker.service stacked dynamic running Docker Application Container Engine

docker.socket stacked dynamic running Docker Socket for the API

As a side note, you can likewise run a contrasting option to the Docker motor, rkt by CoreOS. It is likely that Kubernetes will bolster extra holder runtimes later on.

One week from now we'll find out about systems administration, and keeping up a persistency layer with etcd.

[techcreationstk-blog]

CNCF Accepts Both Docker’s containerd and CoreOS’ rkt as Incubation Projects

In a consistent voting process that closed Wednesday amid KubeCon in Berlin, The Cloud Native Computing Foundation's Technical Oversight Committee affirmed Docker Inc's. movement to give containerd — the present incarnation of its center compartment runtime — as an authority CNCF brooding venture. In a similar meeting, the TOC additionally voted consistently to embrace CoreOS' rkt compartment runtime, too.

"Holder orchestrators require group driven compartment runtimes," peruses a formal articulation from CNCF Executive Director Dan Kohn Wednesday, "and we are eager to have containerd which is utilized today by everybody running Docker. Turning into a piece of CNCF opens new open doors for more extensive coordinated effort inside the biological system."

Starting at now, the motor that reasonable enables a lion's share of the world's virtual workload compartments is no longer claimed by Docker, however is rather administered by an autonomous body whose participation incorporates Docker.

That Docker Inc. had an enthusiasm for giving containerd to an outside association has not been a mystery. Amid a Docker-facilitated assembling of designers around containerd in San Francisco a month prior, the organization recognized the probability of such an exchange occurring. Furthermore, as of late as two weeks back, CNCF TOC part and Docker Chief Technology Officer Solomon Hykes told the CNCF it was his organization's expectation to successfully strip itself of what restrictive rights it has to the product, yet had not chosen how.

"The expectation is to move to a github organization that 1) is not Docker-marked and 2) is controlled by Limix Foundation [sic]," Hykes composed around then.

Hykes additionally reported Docker's expectation to give "different undertakings," without naming names. The main slight resistance Hykes got came immediately from Kohn, who clarified that while his gathering would be upbeat to have additionally extends made by Docker, there might be no immediate advantage for it to give every one of them to a similar establishment.

Other than that note of advisement, there were no protests to Docker's turn, including from CoreOS engineer Jonathan Boulle. Among non-restricting voters contributed by the group everywhere, there was unanimity to support Docker also.

In spite of the fact that the gift signals were not joint or consolidated amongst Docker and CoreOS — as Docker Inc. educated The New Stack not long ago — CNCF individuals learned about both voting dockets through a similar mailing list message.

Documentation presented on GitHub Wednesday finds a way to separate rkt from containerd, making it clearer to newcomers to the venture that the two parts are really not compatible, despite the fact that they've both been called "compartment runtimes." rkt is daemon-less, the documentation noted, and in this manner depending on systemd for their bootstrap, not at all like Docker's containerd.

"With regards to the obstinate and checked nature of the venture," the CNCF documentation goes on, "rkt does exclude any local work processes for building holder pictures, yet is somewhat anticipated that would be utilized as a part of conjunction with manufacture frameworks, for example, the Dockerfile, acbuild, or box ventures."

Whither CRI-O

One issue for the CNCF Kubernetes compartment orchestrator designers among the CNCF — if not currently, then soon — will be the means by which they expect to continue with their Container Runtime Interface (CRI) extend. Its plan, as Google Engineering Manager and Kubernetes lead designer Tim Hockin called attention to amid Docker's in-house summit a month ago, is to empower an assortment of compartment runtimes to wind up plainly pluggable into Kubernetes. Presently, CNCF is the steward of a dominant part of that assortment.

Hockin communicated his proceeded with reservations about his group's choice to fabricate CRI on top of Docker Engine. Among them, he stated, "the bind of calls to make a holder is truly amazing," outlining four bounces from a kubelet to the runc segment. In the event that something turns out badly along each of those jumps, he cautioned, it is hard to follow. What's more, when Docker rolls out an improvement to its motor, he included, "it turns into a greater and greater undertaking for us to qualify new forms of Docker, which soften up new and intriguing ways, or simply present new, extremely inconspicuous incongruencies, and those don't present to us any esteem."

This had been the motivation for the CRI-O extend — a push to manufacture a runc-based, run-just compartment runtime that would empower Kubernetes to run holders that were at that point constructed. Be that as it may, for this gathering, Hockin recommended rather a change to direct support for containerd.

"It is by all accounts a vastly improved fit, a much lower-level primitive than what Docker's giving us through the Docker API," Hockin clarified, "which is precisely what we require. Truly, containerd couldn't have been planned better for what we need out of Kubernetes."

So no doubt Wednesday's finished exchange shows the blessing to Hockin and his partners that CRI-O would have displayed, had business as usual remained the norm (which it never does). Simply a weekend ago, a proof-of-idea bundle for incorporating containerd straightforwardly with Kubernetes, was presented on GitHub.

Hockin tweeted the presence of the POC venture, and afterward soon thereafter caught up with this note: "In a really open venture, no one can make you critical, aside from yourself. No one but you can make you essential."

[foxutech]

Docker Security: Best Practices for your Containers

Docker Security: Best Practices for your Containers

Operating systems like CoreOSuse Docker to run applications on top of their lightweight platform. Docker in its turn provides utilities around technologies like Linux container technology (e.g. LXC, systemd-nspawn, libvirt). Previously Docker could be described as the “automated LXC”, now it’s actually even more powerful. What it definitely is simplifying and enhancing the possibilities of…

[animacionesadultos]

CoreOS with Caddy walkthrough (featuring SYSTEMD, Route53, Droplets, PHP & DOCKER)

CoreOS with Caddy walkthrough (featuring SYSTEMD, Route53, Droplets, PHP & DOCKER)

http://showanimaciones.com/coreos-with-caddy-walkthrough-featuring-systemd-route53-droplets-php-docker/ ANIMACIONES PARA CUMPLEAÑOS EN: showanimaciones.com This setup has several advantages:

* ~30LOC configuration * Host (coreos) stays current with latest security updates * Docker image stays upto date with Docker pull between boots *…