This second blog post (and talk) is primary scoped to container runtimes, where we will start with their historic origins before digging deeper into two dedicated projects: runc and CRI-O. We will initially build up a great foundation about how container runtimes work under the hood by starting with the lower level runtime runc. Afterwards, we will utilize the more advanced runtime CRI-O to run Kubernetes native workloads, but without even running Kubernetes at all. Introduction In the previous part of this series we discussed Linux Kernel Namespaces and everything around to build up a foundation about containers and their basic isolation techniques. Now we want to dive deeper into answering the question: “How to actually run containers?”. We will do so without being overwhelmed by the details of Kubernetes’ features or security related topics, which will be part of further blog… Leggi tuttoDemystifying Containers – Part II: Container Runtimes

This series of blog posts and corresponding talks aims to provide you with a pragmatic view on containers from a historic perspective. Together we will discover modern cloud architectures layer by layer, which means we will start at the Linux Kernel level and end up at writing our own secure cloud native applications. Simple examples paired with the historic background will guide you from the beginning with a minimal Linux environment up to crafting secure containers, which fit perfectly into todays’ and futures’ orchestration world. In the end it should be much easier to understand how features within the Linux kernel, container tools, runtimes, software defined networks and orchestration software like Kubernetes are designed and how they work under the hood. Part I: Kernel Space This first blog post (and talk) is scoped to Linux kernel related topics, which will… Leggi tuttoDemystifying Containers – Part I: Kernel Space

From php version 5.3.0 we can use the directive mail.log to log who’s calling the function mail(). When someone calls the function mail() from a php script we can get some info about the sender in our log. I will enable logging globally. You can choose yourself where to activate it, editing your php.ini for cli, cgi, apache2, fpm… To enable it globally: sudo echo “mail.log = /var/log/phpmail.log” > /etc/php5/conf.d/mail.ini phpmail.log is the log filename used in my example. Then create the file: touch /var/log/phpmail.log chmod 777 /var/log/phpmail.log …and restart apache or process manager you are using: /etc/init.d/apache2 restart or /etc/init.d/php5-fpm restart

Linux has many tools available for troubleshooting some are easy to use, some are more advanced. I/O Wait is an issue that requires use of some of the more advanced tools as well as an advanced usage of some of the basic tools. The reason I/O Wait is difficult to troubleshoot is due to the fact that by default there are plenty of tools to tell you that your system is I/O bound, but not as many that can narrow the problem to a specific process or processes. Answering whether or not I/O is causing system slowness To identify whether I/O is causing system slowness you can use several commands but the easiest is the unix command top. # top top – 14:31:20 up 35 min, 4 users, load average: 2.25, 1.74, 1.68 Tasks: 71 total, 1 running, 70 sleeping, 0… Leggi tuttoTroubleshooting High I/O Wait in Linux