In a previous post, I showed how to automate a PostgreSQL fault-tolerant cluster with Vagrant and Ansible.
This kind of setup makes our database cluster resilient to server failure and keeps the data available with no need for human interaction. But what about the apps using this database? Are they fault-tolerant too?
This is the final part of our Kubernetes logging series. In case you missed part 1, you can find it here. In this tutorial, we will learn about configuring Filebeat to run as a DaemonSet in our Kubernetes cluster in order to ship logs to the Elasticsearch backend. We are using Filebeat instead of FluentD or FluentBit because it is an extremely lightweight utility and has a first-class support for Kubernetes. It is best for production-level setups.
Filebeat will run as a DaemonSet in our Kubernetes cluster. It will be:
In AWS, we have several ways to deploy Django (and not Django applications) with Docker. We can use ECS or EKS clusters. If we don’t have one ECS or Kubernetes cluster up and running, maybe it can be complex. Today, I want to show how deploy a Django application in production mode within a EC2 host. Let’s start.
The idea is create one EC2 instance (one simple Amazon Linux AMI AWS-supported image). This host doesn’t initially have Docker installed. We need to install it. When we launch one instance, when we’re configuring the instance, we can specify user data to configure an instance or run a configuration script during launch.
The Istio traffic management model basically allows for the decoupling of traffic from infrastructure scaling, allowing operations personnel to specify the rules to apply to traffic using Pilot instead of specifying which pods/VMS should receive traffic. Decoupling traffic from infrastructure scaling allows Istio to provide a variety of traffic management functions independent of application code. The Envoy sidecar proxy implements these functions.
In a typical mesh, you often have one or more finalizing external TLS connections at the end to guide traffic into the mesh’s load balancer (known as a gateway); the traffic then flows through internal services after the sidecar gateway. The following figure illustrates the use of gateways in a mesh:
