Application migration to Docker containers -part 1 out of 7
Andrey Smetanin
Advanced diploma in Computer Systems Technology, Bachelors in Telecommunications
Docker containers are symbolizing a modern shift towards more agile and efficient software life-cycle management. They provide portable solution that ensures consistency across multiple development, testing, and production environments. Recently, a project was undertaken to migrate a simple, traditional web application to Docker. In this document, we will outline the entire process.
1. Initial state
The web application in question is quite straightforward, displaying Google Calendar for the entire year in a simple text format. Google Calendar provides a similar and quite handy feature known as ‘Schedule’.
However, this feature only displays events from the current date onward and the interface is cluttered with various menus and buttons. In contrast, the application presents a clean page to the user with a list of all appointments in a miniminalistic manner.
Moreover, the application displays an entire year centred on the current date, showing six months before and after today. It’s often beneficial to view past appointments alongside the future ones on the same page. The duration of this ‘year window’ can be adjusted as required. The application is designed solely for viewing user’s agenda and does not imply modifications to the calendar. For creating appointments, user supposed to utilize the standard Google Calendar page.
Let’s dig into how the process functions in a traditional setup. The user has a registered domain that points to their public IP address. As part of this configuration, there’s a script from the service provider that executes regularly, updating the user’s dynamic public IP on the DNS server. This script is crucial for addressing potential IP changes that may occur due to power outages or firewall reboots. It’s essential to recognize that this script is distinct from the application mentioned earlier and is not part of the migration.
When the user inputs their registered DNS name into the browser, the traffic is channelled to their firewall and then redirected to a virtual machine (VM) located in their local data center, which runs an Apache web server. This server presents a single static HTML page that displays the user’s current agenda. The HTML page is the result of a series of bash scripts that function within that same VM.
At the heart of it all is a Python script known as ‘gcalcli.’ This publicly available software is quite powerful and offers many interesting features, most of which are not used in this application
The main output of the HTML page itself is created by the following shell script, called "calendar.sh".
#!/bin/bash
d=`date`
fd=`/bin/date --date=" 6 month" +%Y-%m-%d`
pd=`/bin/date --date=" 6 month ago" +%Y-%m-%d`
cd=`/bin/date +%F`
before=`/usr/local/bin/gcalcli --cal [email protected] agenda $pd $cd`
after=`/usr/local/bin/gcalcli --cal [email protected] agenda $cd $fd`
echo "$before"
echo "---------------------------------------------"
echo "$after"
echo "Generated on $d"
Here’s the detailed explanation of each line in the provided shell script:
? #!/bin/bash: This is the shebang line. It tells the system that this script should be run in the Bash shell, regardless of which shell the user is currently in.
? d=$(date): This command assigns the output of the date command (current date and time) to the variable d.
? fd=$(/bin/date --date=" 6 month" +%Y-%m-%d): This command calculates the date 6 months in the future from today and assigns it to the variable fd in the format ‘YYYY-MM-DD’.
? pd=$(/bin/date --date=" 6 month ago" +%Y-%m-%d): This command calculates the date 6 months in the past from today and assigns it to the variable pd in the same format.
? cd=$(/bin/date +%F): This command assigns the current date in the format ‘YYYY-MM-DD’ to the variable cd.
? before=$(/usr/local/bin/gcalcli --cal [email protected] agenda $pd $cd): This command uses gcalcli, a Google Calendar command-line interface, to fetch the agenda from the user’s calendar starting from the date stored in pd up to the date stored in cd. The output is assigned to the variable before.
? after=$(/usr/local/bin/gcalcli --cal [email protected] agenda $cd $fd): Similar to the previous command, this fetches the agenda from the date stored in cd to the date stored in fd, and the output is assigned to the variable after.
领英推荐
? echo "$before": This prints the content of the variable before to the terminal.
? echo "---------------------------------------------": This prints a line of dashes to act as a separator.
? echo "$after": This prints the content of the variable after to the terminal.
? echo "Generated on $d": This prints the phrase “Generated on” followed by the content of the variable d, which is the date and time when the script was run.
The script essentially prints out a Google Calendar agenda for dates 6 months before and after the current date, with a separation line between past and future events. It also indicates when the report was generated.
Generated output is redirected to the next shell script called ‘ansi2html.sh’. This is publicly available software which converts Linux terminal output to HTML saving the format and colours.
The redirection itself happens within the 3d script ‘cal_html_gen.sh’, which is running the first two scripts and creating the HTML web page.
#!/bin/bash
/scripts/calendar.sh | /scripts/ansi2html.sh > /www/cal.html
Here’s an explanation of each line in the provided bash script:
? #!/bin/bash: This is the shebang line, which tells the operating system that this script should be run in the Bash shell. It’s used to specify the interpreter for the script.
? /scripts/calendar.sh | /scripts/ansi2html.sh > /www/cal.html:
o /scripts/calendar.sh: This is the path to a script named calendar.sh. This script is executed first.
o |: This is the pipe operator. It takes the output of the calendar.sh script and uses it as the input for the next command.
o /scripts/ansi2html.sh: This is another script that presumably converts ANSI (American National Standards Institute) coded text output to HTML format.
o >: This is the redirection operator. It takes the output of the ansi2html.sh script and redirects it to a file.
o /www/cal.html: This is the file path where the output (now in HTML format) is saved. This file will contain the HTML version of the calendar data.
The entire line is a chain of commands where the calendar.sh script generates some output, which is then converted to HTML by the ansi2html.sh script, and the resulting HTML is saved to the cal.html file in the /www directory.
Here is the simplified view of the application logic and traffic flow below:
The primary script, ‘cal_html_gen.sh,’ is scheduled to run on an hourly basis as part of a cron job setup. The ‘gcalcli’ Python script, which is integral to the process, requires an initial authentication step that will be covered later. The Apache Web Server is configured to handle HTTPS traffic, secured through the Let’s Encrypt certification service. This involves two additional scripts: one for requesting the HTTPS certificate and another for monitoring the renewal timeline. We will address the specifics of these procedures later as well.