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