Some days ago I released openstackcli, a new containerized tool to work with Openstack API. The motivation of this project was driven by a missing feature from OVH’s Managed Kubernetes: Snapshots from in-use volumes. If you are already working with Kubernetes, you would like to perform everything in a Kubernetes way, including volume’s snapshots, and this is possible as you can see in the docs. That would be as easy as:
Having several users in a GIT hosting service is really normal: a user for your professional projects, a user for a company that you work with/for, a user for your pet projects and so on. Different users need different registered SSH keys in the same GIT service provider, so your PC can raise some messages like the following when you try to clone a project: Permission denied, please try again.
One of the first steps when you work with data which must be stored is to estimate the disk size. This is really hard, especially when your application is new. Working in a cloud environment gives us the flexibility of using the resources that we need in almost any moment without wasting our money in resources that we will use in the future, if everything goes right. If your application is working in a cloud virtual machine and it needs to store some data, the approach would be to attach a new disk for this data, instead of using the default disk of the virtual machine.
Do you like comics? I am sure that you do. You can find a lot of them on The Eye web, so I have been playing with a project using Go in order to download the comics to read them when you whish, Comiccon. Comiccon is a toy project to download and keep updated comics. It takes advantage of the goroutines to download several comics at the same time. The limitation is the number of your CPUs.
We all know the potential of having Kubernetes in production. How easy is to build distributed systems and maintain them. When you want to locally test your complex application there are some tools like: minikube or microk8s what are really good, but they are one-single node cluster. What happen when I want to test my application, locally, but even closer to a real environment? To help with this issue, I have been working on a project which uses Vagrant to create a bunch of virtual machines which will work as Kubernetes nodes, and other stuffs that we will see later, and Ansible to configure them.
Opensouthcode is an event whose target is to promote open source code technologies and is based on Málaga (Spain). This year I was there talking about Infrastructure as code using Terraform and showing some examples that were deployed to AWS: from a simple server to a Kubernetes cluster. If you want to learn more, check all the sources: Githug repo with the examples Slides (Spanish)
Python is one of the most used languages because the ramp up is really low. A good example is the API of ayncio for building I/O bound applications. Creating asynchronous code could be really tough, but using asyncio could be a child’s play. We are going to try to build a simple chat server in this post using Python 3.7. As the server will be a TCP server, the clients only need to use Telnet to interact with.
Last week I felt so nostalgic about working with Mesos because I do not have more projects which work with this technology and people are only demanding Kubernetes. Mesos is a project which was born in Berkeley, now under the Apache umbrella, and whose target is the management of computer clusters. It will help us to create distributed systems with the feeling that we are only working with a really big machine.
Recently I worked in a project where I had to migrate a Mesos infrastructure to Kubernetes and one of the key requirements was to replace ELK (elasticsearch - logstash - kibana) with EFK (elasticsearch - fluentd - kibana). You can find a lot of information of how to use EFK in Kubernetes when your applications logs in the standard output putting a Fluentd agent in every node, but that did not happen with all the applications in the Mesos infrastructure.
Kubernetes is becoming the standard container orchestrator because of many reasons: Open Source Google Huge community Developed in Go and so on Today we can work in very complex projects which involved too many languages and technologies. Containers (like Docker) and orchestration tools help a lot in these cases. Elixir and Erlang are two languages that I work with, especially when I have to deal with problems of concurrency and low latency.