Building Nginx RPM from source

NOTE: As software advances, some of the commands shown below may become depreciated/irrelevant. If one encounters errors - check the output logs to see what the issue is (e.g. missing library? missing dependency? wrong folder structure due to being unable to find a file)

For the following commands below, we need to run the following code on a machine running Centos OS 7 or in a VM running Centos OS 7. We cannot run it in docker. This is because systemd is not exactly available/useable in docker - there are hacks, but its better to just proceed on to just run these in a Virtual Machine

These are some notes when it comes to building Nginx RPM for centos use. This can be used to further customize Nginx RPM

Create a Google Compute Engine with Centos 7 OS

Install required yum dependencies - some are needed to run commands (e.g. make, wget, git etc)

sudo yum install -y git wget make \
  gcc rpm-build GeoIP-devel zlib-devel \
  pcre-devel gd-devel libedit-devel which \
  perl-devel perl-ExtUtils-Embed libxslt-devel \
  openssl-devel

Import the nginx source code. Apparently, google mirrored the mercurial nginx source code to the following repo. We can safely use git to clone the source code and then checkout out one of the latest version of nginx and try to build up the rpm.

# Clone source code
git clone https://nginx.googlesource.com/nginx-pkgoss

# Enter the folder which contains source code
cd nginx-pkgoss

# Go to specific version of nginx release
git checkout nginx-1.19.8

# Go into rpm folder to view the Makefiles
cd ./rpm/SPECS

# Run make command to build all modules - there are other options
# The main one to ensure that it is possible to build would be "base"
make all

View the built rpm and test it out to ensure that we can run it etc

# Find the built nginx rpms
cd $HOME/nginx-pkgoss/rpm/RPMS/x86_64

# Install the dependencies for nginx
sudo yum install -y openssl
# Check openssl version to ensure its installed
openssl version

# Install the built nginx rpm
sudo rpm -i nginx-1.19.8-1.el7.ngx.x86_64.rpm 
# Check nginx is installed and is available for use
nginx -V

# Start nginx
sudo systemctl start nginx

# Check to ensure that nginx is working and is in running state
sudo systemctl status nginx

# Run curl command to ensure that nginx is able to actually serve the traffic
curl localhost

This should be the output you should be receiving to show that nginx server is properly started and can receive traffic accordingly

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Setting up Observability Tooling in GKE

1 September 2021·Updated: 5 September 2021·2418 words·12 mins

Google Cloud Kubernetes Google Cloud Kubernetes

Generally, most cloud providers come along with all the observability tooling that you need for your apps built-in with the platform. Some of the common observability tools such as logging, monitoring and nowadays, distributed tracing are usually made available and you can easily use said tools by reading up on the various documentation of how to setup each of these tooling. E.g. if your application is inside a virtual machine and if you need collect metrics and logs from the application, you may need to install an agent in the said VM. The agent would collect those information and send it to the centralized observability tooling in the cloud provider where the information would be provided to you via a UI. Most of the time, these tools are charged based on the amount of logs/metrics you generate from the application (so the less logs/metrics you generate, the cheaper it is monitor your application - a very understanable/reasonable situation). In cases where if your application runs in Kubernetes, maybe the cluster comes with agents pre-installed, making it easier to make use of the logging/metrics/distributed tracing that the cloud provider has.

Related