After many years, I participated in an event organised in collaboration with the University of Mauritius. Ten years ago, around this time of the year the Linux User Group of Mauritius and the UoM Computer Club (2013) organised a Linux Festival at the Paul Octave Wiehe Auditorium. Last Saturday's Google Developers Festival (DevFest) 2023, being held on the campus of the University of Mauritius, brought back memories of those days. It also reminded me that it's been a decade since I am actively contributing to the tech community. 🎊🤓

Some happy tears flow down the cheek. Sniff!

Okay, let's talk about DevFest 2023. DevFest is an annual tech conference organised globally by the Google Developer Groups (GDG) community. This year marked the 5th edition of DevFest Mauritius. It was hosted by GDG Mauritius and the University of Mauritius (UoM). The Google Student Developer Clubs of UoM, University of Technology, Polytechnics Mauritius and the African Leadership College helped in spreading the word.

Registration for the event was done through the GDG Mauritius chapter page on the Google Developer Groups Bevy platform, while information about the event, the agenda and the speakers was also available at devfest.mscc.mu.

We had 20 speakers from different tech backgrounds — web development, mobile application development and systems/cloud engineering.

My presentation was scheduled at 11:30 a.m. in the G2 room of the Faculty of Law & Management. I started the presentation sharp on time to be able to stay both on track and on time, as for the next 45 mins, I had planned a whole journey of writing code to deploying the same on a cluster of servers.

PHP is still relevant in 2023. It still powers a lot of websites on the Internet. Even Facebook started on PHP and later created the HipHop Virtual Machine (HHVM) to compile PHP source code to HipHop bytecode for faster execution and then they created the Hack programming language.

I started the presentation by talking about PHP.

If you are just starting with PHP development, I suggest that you closely follow the works of a PHP framework, like Laravel or Symfony. I use Laravel a lot — in fact most of my web related work is now on Laravel. During the presentation I mentioned how lexpress.mu moved from Drupal to Laravel.

My next slide had a few commands needed to create a Laravel project and to run it locally (assuming that PHP and composer are already installed on that machine).

Now, that we had a codebase and we made our desired modifications to the Laravel code, it was time that we thought about packaging it and shipping it to the cloud. The easy way — containers!

SUSE Base Container Image (SUSE BCI) enters the scene. We can of course find plenty of PHP based containers to ship the code, then why SUSE BCI? The short anwser is compliance. Very often if you are working for a big company, there are rules to use software that have enterprise support. SUSE BCIs are enterprise-ready container images based on the SUSE Linux Enterprise Server (SLES). One can purchase a support subscription for the container or inherit an existing subscription from a host SUSE Linux Enterprise Server.

I talked about the Base Images and the Language Container Images. For our need to ship the Laravel codebase, we looked at the three SUSE BCIs that support PHP.

The ideal candidate was the SUSE BCI PHP-Apache 8 image. Our Laravel code is actually this year's DevFest Mauritius website. We do not require a database. The conference schedule and speakers details are pulled from a Sessionize.com API and kept as JSON locally. Therefore, a single container to run the PHP code and serve the HTTP content would be fine.

I spoke about the three SUSE BCIs for PHP and possible use cases on different types of PHP scripts or applications we may run.

Okay, it's good that we have a container to run PHP code but it's not great, yet — because it cannot run "our" PHP code. Laravel 10 requires PHP version 8.2 to run whereas the SUSE BCI has PHP version 8.0.30 as latest version.

Most Enterprise Linux distributions support packages for as long as security fixes remain available for the package. That is the case with SLES and PHP 8 here. The latest version of PHP available from the official SLE_BCI repo is PHP version 8.0.30 which will continue to receive security fixes until the end of November this year, then the package will be upgraded to version 8.1.x which will receive security fixes until November 2024.

Then, how can we use the SUSE Linux Enterprise container but with PHP version 8.2?

Comes into the scene, SUSE's own Open Build Service.

I explained how Open Build Service (OBS) allows one to compile software and package the latter for different Linux distributions and different CPU architectures. Then, I mentioned build.opensuse.org where SUSE upstream projects reside. Recently, the Linux Foundation decided to build Kubernetes packages using OBS too. I talked about how openSUSE Leap and SUSE Linux Enterprise share a 1:1 binary compatible codebase.

One could build PHP v8.2.12 packages using build.opensuse.org but... there is actually no need — because v8.2.12 is already built for SLE 15 SP5. 😎 We can simply add the OBS repo to our SLE BCI Apache-PHP container and install the latest version of PHP.

Huh! So, by this time we have a codebase, we have chosen a BCI and we know how to get the latest version of PHP running which is required for our application (i.e the website of DevFest Mauritius 2023). What's next? We need to build a container image that will hold our codebase and be ready for shipping.

So... Let's build it!

Before talking about building containers though, I mentioned that I don't like the idea of simply copying Dockerfiles from the Internet and start using. Writing a Dockerfile is not difficult and a lot of times it requires just a few lines. It also helps us keep things clean and we know what we are doing.

Let's write a Dockerfile then.

During the presentation, I explained what each line does. Especially, why I chained the RUN commands in one line instead of multiple RUN commands. Each RUN command creates an OverlayFS layer and takes up a little more space. In this example, it would have taken an additional 8MB if we had used multiple RUN commands for every CLI command specified.

FROM registry.suse.com/bci/php-apache:8

In the first line, we pull the SUSE BCI PHP-Apache 8 image. Then, we copy our project directory inside the container image at a specific path which we have specified in an Apache configuration. I talked briefly about Apache VirtualHosts.

COPY ./devfest2023 /srv/www/vhosts/devfest2023
COPY ./devfest2023.conf /etc/apache2/vhosts.d/devfest2023.conf

Next, we copy a "repo" configuration file that contains information about the OBS repository.

COPY ./obs_php.repo /etc/zypp/repos.d

The content of the .repo file is available from the PHP package project on build.opensuse.org.

We run the zypper ref command to update the repo database. We update the packages with the --allow-vendor-change option. Without this option, it will not upgrade PHP because the currently installed PHP package by vendor SUSE is the highest version available. By allowing vendor change, the package will be upgraded using newer packages from the OBS repository.

RUN zypper ref; zypper up -y --allow-vendor-change; \
zypper in -y php8-tokenizer php8-iconv php8-intl php8-bcmath \
php8-bz2 php8-ctype php8-gd php8-posix php8-readline

We install a few other PHP libraries that will be required by our Laravel application.

Laravel writes to a log file stored at the storage/laravel.log path. Therefore, ownership of the directory is changed to the user wwwrun which is the user that owns the Apache child processes.

chown -R wwwrun:wwwrun /srv/www/vhosts/devfest2023; \

We enable the mod_rewrite module in Apache because we have a Rewrite Rule in our Apache configuration that forwards all requests to the index.php file.

a2enmod rewrite

Lastly, we make the container reachable on port 80.

EXPOSE 80

Our Dockerfile is ready. We can build the container image.

I explained what each of the options does in the docker build command. After building the image, we can run a container locally to test the application.

docker run —-rm -p 8080:80 devfest:2023

Once again, I explained what each of the option in the above command does.

So, we've built a container image successfully, we've tested our application running inside a container, what do we do next? Deploy to Google Kubernetes Engine (GKE)? Not, yet. We need to push this container image to a registry, from which GKE will be able to pull and deploy.

Hereon, we started talking about the Google Cloud Platform. We needed to enable two services on GCP before we can ship a container and deploy our application. The services are:

• Artifact Registry API
• Kubernetes Engine API

I explained that previously we would use the Container Registry API but that was only limited to Docker container images. The Artifact Registry can hold repos for container images, npm packages, python, etc.

We created a repository in the Artifact Registry, we specified the format as Docker and we selected a region. We discussed about this choice (i.e region) for a while. My usual trick for obtaining the best latency to a "region" is to understand how our submarine fiber cables connect us to the rest of the world. Since, the SAFE/SAT-3/WASC submarine cable connects us to the west side of the European continent, for this example we chose the europe-west1 region, which is in Belgium. Not too far from the landing point in Portugal? 🤔 Anyway, let's continue...

After creating the repository, the GCP console redirects to the repository details page. I encircled the path which we need when pushing the container image to the registry.

Oh... wait. Before pushing our container image to the Google Artifact Registry we need to setup authentication for Docker. Read the instructions here. During the presentation I did not elaborate on the Docker/GCP authentication part as it is purely textbook instruction.

We're almost there. We have built our container, we have set up our repository on Google Cloud, so now let's do the next step.

We tag the local image devfest:2023 (which we built earlier) using the path we saw on the repository page. I explained each item in the command for clarity.

Then, we run:

docker push europe-west1-docker.pkg.dev/devfest2023-403313/mscc/devfest:2023

You can see the progress as each layer is being copied to the registry. When completed, refresh the registry page on the cloud console.

Hereon, we started talking about Kubernetes and its complexity. However, Google (and other cloud providers) offer a Managed Kubernetes Service. Managed meaning — the implementation and related complexities are obsfuscated. Thus, as a developer you should be able to deploy your application in a cluster with minimal effort. That's exactly what Google Kubernetes Engine is about.

You click on the three dots and select "Deploy to GKE".

The first option is to select a container, but here the devfest:2023 container is pre-selected. You can add environment variables which you usually do through the .env file of a Laravel application. Since, we are not using a database or require any other specific info to pass on, we can skip this part.

GKE creates a deployment configuration which defines the state of the cluster. It uses defaults here, e.g the replicas (i.e no. of nodes in the cluster) to 3. All of this information can viewed in the YAML file which is accessible from the page.

The YAML file is read-only at this point. We cannot edit the deployment configuration but we can do so once the cluster is created. Then, we can edit the YAML config to adjust it to our needs or use other "buttons" in the console to scale the cluster up/down, horizontally or vertically.

After the configuration part, the last step is to select whether we want to create a service to expose the cluster. Since, we want our application to be available on the Internet, we expose the cluster on port 80.

After we hit "DEPLOY", GKE starts building the cluster.

For this example, the cluster was ready in less than 5 mins.

Once the cluster is ready, the deployment details page will display information regarding the availability and health of the cluster nodes. At the bottom of the page, the endpoint in the Expose services show the Public IP Address for the deployment. Click on that and you can access your application. In our case, we were able to see the DevFest Mauritius 2023 site hosted on the IP address.

That was my share of contribution to DevFest Mauritius 2023, as speaker this year. I hope everybody who attended the session enjoyed it and learned at least a thing or two. 😊

The day started similar to DevCon 2022 days... waking up at 04h00 and hitting the road by 06h30. Shelly & I picked up Pritvi, Girish and Vidush along the way. We reached the ALC campus by 08h00. As we arrived at the campus' security checkpoint, Shelly got down from the car and explained the security personnel about the event and handed her the list of attendees. This was a security requirement by ALC — they needed the names of all attendees in order to allow them to access the college premise. Totally understandable, it's a college and they have rules.

As we moved to the parking area I noticed JoKi's Mitsubishi SUV. Seconds later I saw JoKi walk by and we waved. Mary Jane was already at the cafeteria's entrance where the registration desk was meant to be. In fact, they had started setting up that area — with the tables and roll-up banners. The DevFest 2022 backdrop was yet to be set up. Pritvi gave a helping hand with that.

The opening ceremony was held in the cafeteria. Few minutes before it started, JoKi checked the sound equipment and tested his laptop display on the TV. Meanwhile, registration was in full swing.

Registration was faster and smoother with the QR verification. Once checked-in, attendees received their DevFest attendee badge, a t-shirt, stickers and a 50% discount voucher by cloud.mu.

Attendees spread around the campus checking the presentation rooms, sponsors area, meeting people, etc.

At 09h00, everyone came to the cafeteria for the opening ceremony. DevFest 2022 kicked-off! JoKi welcomed everyone and explained about the Google Developer Groups around the world and what is DevFest. He invited Yovin Poorun, Computing Degree Program Lead at the African Leadership College, to address a few words.

Yovin's support and assistance in making the DevFest 2022 happen at the African Leadership College was greatly appreciated.

Then, Didier Béphage, Technology Director at SD Worx addressed a few words. SD Worx was one of the sponsors of DevFest 2022 and they have continuously supported local dev activities in Mauritius.

Didier spoke about SD Worx and the company's culture. He went through some details as JoKi displayed the company's website on the TV.

The first presentations in Rooms 1 and 2 were started at 10h00.

My talk was scheduled at 11h00 in Room 1. I reached there a few mins before, as Dhanesh was concluding his presentation on CI/CD in Google Cloud. My talk was about deploying a Laravel application on the Google Kubernetes Engine.

I started with explaining about Laravel. It is an open-source project, it has great documentation, it follows the MVC principle, it has several first-party packages and deployment is a piece of cake (like most PHP applications).

I spoke about the Laravel ecosystem, tools such as Forge and Vapor, starter-kits like Breeze and Jetstream — how they all make development less of a struggle.

I touched on the Model-View-Controller subject and explained how the data, the design and the logic are kept separate, giving the developer better control over the code.

Then, I mentioned Laravel Bootcamp, for anyone wishing to start Laravel development. Bootcamp is ideal for somebody who is just starting a career in webdev to get an idea on how full-stack development is possible with Laravel. One may choose to write all the backend logic in PHP and design fancy pages using either Blade templates, Vue.js or React.

A Laravel project can be created with just a few commands. Adding Breeze to that, we can have an authentication feature built into the app instantly.

Say we have a working Laravel project... how do we deploy that on Kubernetes. Not just, yet. We need to break down the application components such that the code can run on as many instances while the application data resides on a centralised location which every instance can access.

Thus, we can move the database to Google Cloud SQL and the file storage to Google Cloud Storage. We are then left with just the application code and some binaries required to run the application — which can now be multiplied on as many virtual machines as we need or deploy them in containers in a Kubernetes cluster.

I spoke about the advantages of using a managed Kubernetes platform such as the Google Kubernetes Engine (GKE).

Kubernetes is being actively developed. A one-man army cannot simply develop applications and manage Kubernetes clusters on his own. GKE provides plenty of options for a DevOps to configure how the cluster must run, scale and be cost effective.

GKE provides two types of clusters — standard and autopilot. In the former, you can choose the number of nodes you want in the cluster and provision those nodes according to your needs. You are billed a management fee and also billed for every running node (a Google Compute instance) irrespective of whether there are any workloads running on the node or not.

However, in the autopilot mode, GKE decides what is best. Thus, upon creation there are no running nodes at all in the cluster. Nodes are provisioned when workloads are deployed. You cannot add/remove nodes in the autopilot cluster. Those are done automatically by GKE when the workloads require additional resources or nodes can be scaled down if no more required.

The autopilot cluster is more cost effective because they are not billed per node (i.e per Compute instance) but instead they are billed per pods (calculated as per the amount of resources required by the pods).

During the demo part of the presentation, I created two clusters, one standard and the other as autopilot. I showed that the cost using the default settings in a standard cluster would result in a monthly bill of above $300 even if nothing is deployed. In the autopilot mode, a flat fee of $0.10/hour is applied which results in a $72/month flat amount and each pod is billed individually for the vCPU, memory and ephemeral storage used.

I also explained how pricing changes across different regions while explaining the difference between regions and zones.

Coming back on the discussion on containers, I showed how I containerised a Laravel application and mentioned a peculiar issue that I encountered on my Apple M1 Macbook. The M1 processor is ARM64 and thus the container is built for ARM64. Pushing that container to the Google Artifacts Registry and then deploying it on GKE throws an "exec format error".

It took me a while to realise my mistake — being a relatively new "M1 user".

I should have built the container for the linux/amd64 architecture before pushing it to the Google Artifacts Registry.

JoKi from the audience commented whether the --platform flag couldn't have been specified in the Dockerfile. Yes, that could be done too.

However, in my case, I was building and testing the container on ARM64. Then, for deployment on GKE, I would build the container for linux/amd64 and push it to the Google Artifacts Registry. Therefore, it was easier to specify the architecture at build time instead of hardcoding it in the file.

Lastly, I talked about the gcloud and kubectl CLI tools which I used to interact with the cluster. Using kubectl I obtained information about the pods and I could also investigate the pods individually.

Neil asked whether one could choose the container engine to use by GKE. I answered that GKE would most probably use the CRI-O engine rather than docker-runc. During my experiments I did not find whether GKE could be configured to use a different container engine or a different architecture like ARM64.

That's it! I was able to cram everything in 45 mins.

After my session, I went back to the cafeteria for lunch. Luckily, there was vegetarian food. 🫑🍅🥬

Next, I attended Pritvi's session about improving your exposure as a local guide on Google Maps using Google Lens. I am glad I attended the session. It was very helpful to understand how Google Maps behaves as a social network for "local guides". There is a point system and local guides gain more points for correcting and improving the accuracy of Google Maps — e.g adding a missing place, uploading pictures of a restaurant, the restaurant's menu, uploading building signage etc.

You can follow other local guides and of course others can follow you. You can write reviews about places you visit and people finding those reviews helpful may... well... like the reviews. 😉

Like I said earlier, it was very helpful, educational and an interactive session. In fact, during the session I intervened and explained how I have been trying to remove a wrong pin dropped over my home for some "organic product business" which is nowhere around my place (at least not that I know of). Both Shelly and I tried several times to remove it but nothing happened. Then, during the talk, Chittesh and Aditya requested the removal of that place on Google Maps. It was immediately removed! 😊

After Pritvi's presentation, I remained in the same room to attend Abdur-Rahmaan's presentation about SQLite internals. I very much liked the presentation — digging a piece software to understand how it works internally. Abdur-Rahmaan did just that.

He started with some history about SQLite and its creator Dwayne Richard Hipp. Then, minutes later the discussion changed from story to practicals. He talked about the compiler having a parser and a code generator. The latter produces a bytecode which is then run in a VM — which in turns can be broken into several components to understand each one's functionality — like the role of a pager, btree, shim etc.

He then explained about recovery, how does SQLite avoid data corruption if there is a power outage while some write operation was still happening.

Time was short for this talk but before he completely ran out of time, Abdur-Rahmaan spoke about some alternatives/forks to SQLite — libSQL and LumoSQL.

For me, right there, it was a fruitful day and a very successful DevFest. I shared some knowledge and I learned some.

I briefly attended the last session of the day in Room 2 by Dr. Amreesh Phokeer, a Data Expert at the Internet Society.

He explained about a project he is working on at the Internet Society — Measuring Internet Resilience in Africa (MIRA). He described how he used Google Cloud products such as BigQuery and Looker Studio to create a Data Pipeline.

Lastly, the closing ceremony happened in the cafeteria. There was the list of thank you's, mentioning all sponsors, partners, attendees, volunteers and JoKi thanked the three Google Developer Student Clubs (GDSC) on the island — African Leadership College, Polytechnics Mauritius and the University of Mauritius — while also encouraging them to take the lead in organising future DevFests.

There were some prize giveaways following questions put by JoKi and some of the GDSC Leads.

A fruitful day with lots of learning and sharing! Thank you Google for endorsing and encouraging such activities.