Brain Dumps

Using a HTTP proxy is a boon to performance, especially if you have a slow link to the Internet. However if you’re using Docker in a corporate environment, sometimes you are forced to use a HTTP proxy as outgoing connections to ports 80 and 443 are often blocked. For most applications it’s usually a simple matter of setting an environment variable or changing a config file to configure a HTTP proxy for an application. Docker, though is a little bit tricky to get working as there are no less than four different places where a proxy needs to be configured for it to work correctly. There are four different places where a HTTP proxy can be used in Docker. Between the Docker client and Docker daemon Between the Docker daemon and the Internet At container run-time At container build-time Unfortunately each case needs to be configured differently in Docker. Let’s look at each case individually. Proxy between Docker client and Docker daemon The Docker client is very thin a

I work on monitoring. In particular on  Prometheus , a monitoring system that includes a custom time series database, and its integration with  Kubernetes . In many ways Kubernetes represents all the things Prometheus was designed for. It makes continuous deployments, auto scaling, and other features of highly dynamic environments easily accessible. The query language and operational model, among many other conceptual decisions make Prometheus particularly well-suited for such environments. Yet, if monitored workloads become significantly more dynamic, this also puts new strains on monitoring system itself. With this in mind, rather than doubling back on problems Prometheus already solves well, we specifically aim to increase its performance in environments with highly dynamic, or transient services. Prometheus’s storage layer has historically shown outstanding performance, where a single server is able to ingest up to one million samples per second as several million time serie