Month: September 2020

man in bluee ssweater

How to debug Terraform variable content using this custom module

  

A lot of the time when I’m having to debug Terraform, I find that I want to quickly look at what Terraform may be storing inside a variable so that I can understand where I’ve made a mistake passing data around. After literal years of using the old TF_LOG=debug method – which can get way too unwieldy with any decently sized environment, I realized I could write a simple module to dump out what I was looking for. Hopefully this will help you too.

resource "null_resource" "terraform-debug" {
  provisioner "local-exec" {
    command = "echo $VARIABLE1 >> debug.txt ; echo $VARIABLE2 >> debug.txt"

    environment = {
        VARIABLE1 = jsonencode(var.your_variable_name)
        VARIABLE2 = jsonencode(local.piece_of_data)
    }
  }
}

Just replace var.your_variable_name_goes_here with your actual variable reference and then run your terraform apply. A file should be spit out in the same directory that the .tf file that you inserted this resource lives in, which you can then open up and understand what might be going on.

I don’t know why it took me so long to figure out something so simple, but coming from PHP/Laravel – where you can just dd() or dump() the contents of a variable to the console – the idea of using the local-exec provisioner to debug terraform just never occurred to me.

EDIT [Jan 6, 2020]: Wrapped variable data in jsonencode() to avoid issues with echoing an empty string to a file. Also show how to dump multiple variables to the same file.

lines of HTML codes

Minimize downtime when deploying new code to your Laravel site

     

I deploy my Laravel site using Ploi, but I was facing a problem: since I don’t use the zero-downtime option, how can I minimize downtime when deploying new code to my website?

NOTE: This article will be updated over time with any new tricks I discover so check back to see what else you can do. They should also work with all deployment tools like Laravel Forge and Deployer; I just happen to use Ploi.

Don’t recompile JS/CSS assets if they haven’t changed

There is no sense re-running yarn run prod if there’s nothing to do, so instead of just doing

yarn install --save
yarn run production

or

npm install --save
npm run production

let’s be intelligent about it:

# Dump the list of filenames changed in the last git commit
git diff --name-only HEAD HEAD~1 > /tmp/gitdiff.txt

# First, assume there were no changes
yarn=false

# Read the /tmp/gitdiff.txt file line by line....
while read line; do
    # The regex to search for CSS/JS/Vue/.lock/JSON/PHP files in the resources folder
    # We include PHP here in case you use PurgeCSS
    positiveMatch='^(resources\/|).*(css|js|vue|lock|json|php)$'
    negativeMatch='^(composer|public)'

    # Check to see if any those filetypes are listed 
    if  [[ $line =~ $positiveMatch && ! $line =~ $negativeMatch ]]; then 
        # ...and if so, set the yarn flag to true
        yarn=true
        echo $line
    fi
done < /tmp/gitdiff.txt

# If any changes were detected, run the necessary yarn commands
if $yarn ; then
    yarn install --save
    yarn run production
fi

# Cleanup
yarn=false
rm /tmp/gitdiff.txt

And that’s how you can minimize downtime when deploying new code to your Laravel site!