2019-11-10-deploying-website.html (4884B) - raw

      1 <!-- title: Deploying a website using the WebDAV protocol -->
      2 <!-- slug: deploying-website -->
      3 <!-- categories: FOSS, Personal domain -->
      4 <!-- date: 2019-11-10T00:00:00Z -->
      5 
      6 <p>
      7   Now that my website is <a href="/blog/2019/11/new-host/">hosted by Autistici/Inventati</a>, I can
      8   no longer deploy it by just pushing my git repository's changes to GitLab, as I used to. In order
      9   to deploy my website, I need to access the server using the WebDAV protocol. To do so, I use <a
     10   href="https://savannah.nongnu.org/projects/davfs2">davfs2</a>—which mounts the WebDAV resource—so
     11   I can access it like any other folder in the filesystem.</p>
     12 <!-- /p -->
     13 
     14 <p>
     15   I had never used the WebDAV protocol before, so I used A/I's tutorial. It was was a very simple
     16   tutorial, but it goes straight to the point, without giving unneeded explanations. I set it all up
     17   and edited the <code>~/.davfs2/secrets</code> file to make the mounting process smother. I know
     18   that having a password in plain text is a potential security risk, but the password only gives
     19   access to the WebDAV service (not my whole A/I account) and is easily resettable. If someone got
     20   hold of the password, all they could do is change my website, until I realized it and change
     21   it.</p>
     22 <!-- /p -->
     23 
     24 <p>
     25   Deploying the website would mean copying all the output files from <a
     26   href="https://gohugo.io">Hugo</a>—the static site generator used to build my site—to the specified
     27   folder on the mounted filesystem. The problem was that copying files (as well as removing them)
     28   takes a long time, I am guessing due to A/I's resources' configuration. To give some context, it
     29   took around 1 minute to copy 1MiB worth of files, plus 10 seconds to delete them. So deleting and
     30   copying the whole folder again every time I changed something wasn't a good deploying method
     31   (besides, it wastes resources server-side).</p>
     32 <!-- /p -->
     33 
     34 <p>
     35   The solution I chose was <a href="https://rsync.samba.org">rsync</a>. It is a great piece of
     36   software that efficiently transfers files from one folder to another. It checks the last
     37   modification time and the file size to avoid transferring files that are up to date. I already
     38   knew this program as I use it to back up my computers to hard drives (it reduces the backup time
     39   considerably after the first time), so implementing it should have been a breeze. I encountered
     40   two problems:</p>
     41 <!-- /p -->
     42 
     43 <ol>
     44   <li>
     45     By default, <code>rsync</code> makes use of modification times to check whether a file should be
     46     transferred, but every time I build my site, all files are created again, so the modification
     47     times are always newer than the ones in the server.<br/>
     48 
     49     There is a quick fix for this: the program has an option (<code>-c</code> or
     50     <code>--checksum</code>) that makes the program use the checksum of a file (instead of
     51     the modification time) along with the file size to determine whether it has
     52     changed.</li>
     53   <!-- /li -->
     54   <li>
     55     <code>rsync</code> makes use of auxiliary files while synchronizing them. For some reason (that
     56     I still don't know, my guess is something to do with permissions), when those auxiliary files
     57     are finally renamed to the definitive filename, it fails, giving out an error and exiting
     58     without any file transferred.<br/>
     59 
     60     To fix this issue, I used the <code>--temp-dir</code> option to specify a local directory as the
     61     one that should be used for the temporary files. With that set up, it doesn't give any more
     62     errors.</li>
     63   <!-- /li -->
     64 </ol>
     65 
     66 <p>
     67   So finally the <code>rsync</code> command worked, and the time used to update the website is now
     68   around 10 seconds, which is a lot better than a minute (considering my website might get larger,
     69   the impact can be even bigger). To automate the process I build a little script that will mount
     70   the filesystem, build the site, synchronize it with the server and unmount it again:</p>
     71 <!-- /p -->
     72 
     73 <pre><code class="language-bash"><!--
     74      -->#!/bin/bash
     75 
     76 <!-- -->HUGO_PATH=&quot;{path_to_hugo_directory}&quot;
     77 <!-- -->TEMP_DIR=&quot;{path_to_temp_directory_to_use_with_rsync}&quot;
     78 <!-- -->MOUNT_PATH=&quot;{path_to_the_mounted_directory}&quot;
     79 <!-- -->WEBDAV_FOLDER=&quot;{website_directory_in_webdav_filesystem}&quot;
     80 
     81 <!-- -->rm -rf $HUGO_PATH/public
     82 <!-- -->hugo -s $HUGO_PATH --minify
     83 <!-- -->mount $MOUNT_PATH
     84 <!-- -->mkdir $TEMP_DIR
     85 <!-- -->rsync -ruvc --progress --delete --temp-dir=$TEMP_DIR $HUGO_PATH/public/ $MOUNT_PATH/$WEBDAV_FOLDER
     86 <!-- -->rmdir $TEMP_DIR
     87 <!-- -->umount $MOUNT_PATH</code></pre>
     88 
     89 <p>
     90   As you can see, it is a very simple script. It removes the last built of the site from the local
     91   filesystem and builds it again (using the <code>--minify</code> option to reduce file sizes), it
     92   mounts the WebDAV resource, transfers the files and then unmounts the resource again.</p>
     93 <!-- /p -->