Very young but interesting project.
Might save you from introducing something new your project just for full text search (chances are you probably already have Redis in your tech stack)
Here’s a dockerfile for Redis 4.0 RC3 and Redisearch 0.16 for you to fiddle with.
- The image is based on glibc for wide compatibility
- Using apt package manager for access to large number of packages
- Quicker security updates
Even though there are many complaints about
glibc, it’s still very widely-adopted.
I would hate to debug building libraries with
musl-libc. It’s just not worth it.
Using alpine as base Docker image
13 Apr 2017 • permalink
I recently updated all of my personal Dockerfiles that I have for multiple purposes to use
alpine as base image.
Prior this, I just use
ubuntu as the base image and don’t have much care about built-images size. However, using Kubernetes, having small images size can make rolling out update speed much faster.
Some tips for reducing Docker image size that I found during my research:
- Using smaller base image (alpine, busybox, etc..)
- Remove unnecessary dependencies that you use for compiling stuff after done. (Also remove cache)
- Use few layers as possible. However, I don’t think you should do it blindly just for the shake of small image size and destroy readability. I prefer to keep it simple and clean. Optimize it later for building only.
Setting up traefik as Ingress controller for Kubernetes
04 Apr 2017 • permalink
Just my own experience setting up traefik as Ingress controller on Kubernetes.
brew install kubernetes-helm
Install traefik chart with helm
Download the default
values.yaml file and edit it depends on your needs. Then issue the below command.
I want to install it to
kube-system namespace hence the
helm install --name my-traefik --namespace kube-system --values values.yaml stable/traefik
If you make a mistake and want to remove it
helm delete --purge my-traefik
--purge if you want to reuse the name previously. Otherwise, helm will complain
release xxx already exists.
Update your app
You will have to create an Ingress, a service and a deployment.
Ingress is a rule to help you setup routing traffic from a domain to your cluster service name
Service will expose your pods to be accessible in the cluster by selector (see example)
Deployment is well .. your app deployment.
It will be a whole lot easier if you see this cheese.yaml file
Download the file and
kubectl create -f traefik.yaml to deploy it to your cluster.
In the example above, i will use the domain
Create a CNAME record of
stilton.example.com to point to your traefik’s ELB public address.
If you have traefik dashboard enabled, you should see new ingress and the pods it distributes load to on the web.
PS: You don’t necessarily use
helm. It just make installing stuff a lot easier.
Add support for abi stable module API (N-API) as “Experimental feature”. The goal of this API is to provide a stable Node API for native module developers. N-API aims to provide ABI compatibility guarantees across different Node versions and also across different Node VMs - allowing N-API enabled native modules to just work across different versions and flavors of Node.js without recompilation.
Great news for native module developers :)
Proxy based Redis cluster solution supporting pipeline and scaling dynamically
Just something to keep in mind.
Build Price-Aware Applications
Check the Price History: In general, picking older generations of instances will result in lower net prices and fewer interruptions.
Use Multiple Capacity Pools: By having the ability to run across multiple pools, you reduce your application’s sensitivity to price spikes that affect a pool or two (in general, there is very little correlation between prices in different capacity pools). For example, if you run in five different pools your price swings and interruptions can be cut by 80%.
Debugging why k8s autoscaler wouldn't scale down
11 Jan 2017 • permalink
Symptom: autoscaler works (it can scale up) but for some reasons, it doesn’t scale down after the load goes away.
I spent sometimes debugging and turns out, it’s not really a bug per se. More of a bad luck pod placement on my Kubernetes cluster.
I first added
--v=4 to get more verbose logging in
cluster-autoscaler and watch
kubectl get logs -f cluster-autoscaler-xxx. I notice this line from the logs
<node-name> cannot be removed: non-deamons set, non-mirrored, kube-system pod present: tiller-deploy-aydsfy
This node is in fact under-ultilized but there is a
non-deamons set, non-mirrored, kube-system pod presented, that’s why it can’t be removed.
tiller-deploy is a deployment that comes with Helm package manager.
So it seems I just have to migrate the pod to another node and it’s gonna be fine.
You can also read more on how cluster-autoscaler works here on GitHub