When I connected my laptop running Arch Linux to a new WiFi this morning, it worked for a brief moment then all connections were dropped. Connecting to the same WiFi with phone or Macbook works fine so the problem is at Arch LInux(AL)’s end.
Then I noticed if I do a
route it actually showed 2 entries for the LAN. I took a closer look and saw there were 2 IPs for the wireless interface!
Strange enough if I connect to the hotspot of my phone, AL will also have 2 IPs but the connection is still working.
So I googled a bit why there will be 2 IPs, here’s what I got:
Finally, after I shutdown and disabled the dhcpcd service with
sudo systemctl disable dhcpcd
sudo systemctl stop dhcpcd
and restarted NetworkManager, the problem is fixed. Guess some WiFi AP is more tolerant than others.
This is kind of a textbook case that container is much more efficient than VM. The CI pipeline in comparison uses AWS CloudFormation to build new VMs and drain old VMs to do a rolling update, which takes around 10 minutes for everything even if it’s just 1 line of code changed. I did a new pipeline with BuildKite and Kubernetes and a deploy is done within 2 minutes.
The key points to make the pipeline fast are:
- In the Dockerfile, the part that changes more frequently should be put at the bottom of the file, so that docker can maximise its build speed by using cached intermediate images.
- Reload Kubernetes config maps with this:
kubectl create configmap nginx-config --from-file path/to/nginx.conf -o yaml --dry-run |kubectl replace -f -
- Reload containers with this(I use ECR):
$BUILDKITE_BUILD_NUMBER obviously is the build number environment variable provided by BuildKite.
kubectl set image deployment/my_deployment \
- Finally watch rolling update progress with this command:
kubectl rollout status deployment/my_deployment
BuildKite is a relative new CI toolkit I would like to replace Jenkins with. Here are some pros and cons I thought I could share:
- Designed with containers(docker) in mind.
- Hybrid architecture, console as a hosted service where agents can run anywhere with internet connectivity
- Build pipeline as code, also very easy to write because it’s just yaml
- Parallelism in pipeline
- It’s made in Melbourne
- Artifacts can be stored in own S3 bucket
- Well organised UI with a neat github like style
- If there are lots of agents running, some orchestration is needed
- Some features are in beta quality still
It’s very easy to add this super powerful annotations to Grafana charts. I followed the below instructions and created my first annotation in a few minutes on an existing Grafana + InfluxDB setup.