journal/2024: update "Why DevOps do this?"

Add section on "system administration".

1 files changed, 51 insertions, 12 deletions

diff --git a/_content/journal/2024/why_devops_do_this/index.adoc b/_content/journal/2024/why_devops_do_this/index.adoc
index 12dbe15..628e485 100644
--- a/_content/journal/2024/why_devops_do_this/index.adoc
+++ b/_content/journal/2024/why_devops_do_this/index.adoc
@@ -37,7 +37,7 @@ RUN apt-get install -qq --no-install-recommends -y \
 ----
 
 I don't understand this.
-_Why?_
+_Why?_ ლ(ﾟ дﾟლ )
 Why do you need to install packages _every time_ some developer push
 to new branch.
 
@@ -63,7 +63,7 @@ RUN if test "$dev" = "yes"; then \
 ...
 ----
 
-_Why?_
+_Why?_ ლ(ﾟ дﾟლ )
 
 If you need it, you should build it on the base image and reuse that
 base image during CI/CD.
@@ -82,9 +82,9 @@ This is much worse.
 Installing update without knowing what is being updated may hit you in
 many direction.
 
-Your application at version 1.50.0 may works because no updates.
+The application at version 1.50.0 may works because no updates.
 But, then after new patch release 1.50.1, the image contains an update
-that break your application.
+that break the application.
 You spend night and day looking at the commits that cause it, without
 knowing that something has changes during system update.
 
@@ -93,8 +93,7 @@ knowing that something has changes during system update.
 
 ----
 ...
-RUN cd ${APP_DIR}/ && \
-    npm install
+RUN cd ${APP_DIR}/ && npm install
 ...
 RUN pip3 install -r /tmp/requirements.base && \
 ...
@@ -103,24 +102,64 @@ RUN pip3 install -r /tmp/requirements.base && \
 This case is the same with the first one.
 
 Unnecessarily re-installing the same packages _every time_ CI/CD
-triggered, where you should install it only once on the base image.
+triggered, where you should install it only _once_ on the base image.
 
 _But, but, developer may changes their
 package.json/requirements/go.mod
 anytime..._
 
-You can keep the "npm install/pip install" command in the dockerfile.
-When new dependencies updates, the npm/pip/other should pick up whats
+You can keep the "npm install/pip install" command in the Dockerfile.
+When the dependencies file updated, the npm/pip/other should pick up whats
 new and only download the new packages from external network
 (internet).
-The rest of packages that does not changes should be fetch from cache.
+The rest of packages that does not changes, which already installed during
+building of base image, should be fetched from local cache.
 
-Anyway, your developer should tell you when new dependencies changes,
+Anyway, the developer should tell you when new dependencies changes,
 so you, as _DevOps_ should prepare new base image.
 
 
 === Running two or more services on one container
 
-People do this even its again the
+People do this even it is again the
 https://docs.docker.com/engine/containers/multi-service_container/[best
 practice of container].
+
+
+=== Using Alpine for the sake of smallest image
+
+In 2015, I wrote a
+https://github.com/shuLhan/arch-docker[shell scripts^]
+to create Arch Linux images.
+The smallest possible size I can achieve at that time is around 118 MB.
+
+In the README then I said,
+
+> Arch Linux is become bloated, I recommend to use Alpine Linux for small
+size and probably faster container.
+
+Later, I retract this statement.
+
+Arch Linux is not bloated. Unlike other Linux distro, Arch Linux include
+documentation and development files in one package, while other distro split
+it into "-doc" and/or "-devel" packages.
+
+DO NOT USE Alpine Linux just because you want smaller images.
+Alpine Linux use Musl libc, the core library where every single program depends on, which
+completely different with glibc that used by most Linux distro where you
+probably develop and test your program.
+And, no, Musl is not always faster than glibc.
+If you did not know what is libc and why it will affect your program, please
+do not use it for the sake of smaller images.
+
+
+== On system administration
+
+=== Running as "root" everywhere
+
+(╯°□°）╯︵ ┻━┻
+
+This is a basic 101 Linux system administration that they just ignore it
+completely.
+Not only managing the system as root but they also running the service
+(application) as root.