There are always times that I learned something useful and/or cool which I wish I had known sooner. So, I decided to write these little things down. Maybe these kind of things have the protential to be a series.

I always like to try new things out. So when I saw AWS CLI v2 is generally available, I just upgraded it without checking changes.

One thing I found different after the upgrade is that, seems all outputs are redirected to things like less. It’s somehow inconvenient when calling AWS CLI in a shell script:

One day, I was preparing to remove a no longer needed namespace of one Kubernetes cluster. Before I did that, I checked what’s inside again to be sure.

So I typed $ kubectl get all and see if I missed something. It turned out that several things were not listed in the output, like the ingresses I was expecting.

Currently, this site is hosted on Netlify. I am pretty satisfied and don’t plan to move anytime soon. I also submitted my sitemap to Google for it to index. But the update frequency seems not very high.

Fortunately, Google provides an endpoint for you to notify it. Send a GET request to http://www.google.com/ping?sitemap=${siteMapUrl} and you are done.

But do we have to use curl every time we deploy to tell Google it’s time to fetch our sitemap? Well, life is short, don’t waste time on things like that.

Preface

To save costs on testing environments, we use multuple instance types with 100% Spot ratio and lowest-price allocation strategy for several auto scaling groups.

We combined several instance types like c5.xlarge, m5.xlarge, t3.xlarge, t3a.xlarge. It works fine so far, but t3 and t3a instances come with unlimited credits enabled by default. If applications run on these instances suddenly start misbehaving, the cost will increase after accumulated credits burn out.

After dealing with the vpc-resource-controller, I can finally see the IIS page. But a running sample does not mean anything. So I wrapped a few deployment YAML up to see if our workloads work.

Amazon EKS, which was previously called Amazon Elastic Container Service for Kubernetes, is the managed Kubernetes service of theirs. We already have some services (Linux containers) running on production environments for while. It is battle-tested and works well if you ask me.

Due to the characteristic of several Windows-based services that are unlikely to run on other platforms in the foreseeable future, we have been discussing the feasibility of running Windows Containers on EKS.

I recently passed the Certified Kubernetes Administrator exam. One of the questions I was getting a lot is what motivates me to take the exam in the first place.

A few months ago, I noticed that I couldn’t visit to any .dev domains when using the corporation’s network. It was inconvenient, but I didn’t overthink it at that time.

We all need to debug node program from time to time. If you are using VSCode as your IDE, it’s pretty straightforward.

Debugging with local files is even more comfortable. However, when you need to debug node program in a container, there are a few caveats need to notice.