Add an install script.

[nbering]

I experimented a while ago with making a little shell script that could be used to download, unpack, and install the release binaries.

I was looking at something like NodeJS's one or two-liner installation process, which looks like this:

curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -
sudo apt-get install -y nodejs

I experimented with this a while ago, and found the most difficult part was detecting the right OS and architecture. Every POSIX system is a little bit different about how it presents these from the various system information commands.

Here's what I came up with in that experiment (running on Ubuntu):

#!/usr/bin/env bash

TEMPFILE=`mktemp`
echo "TEMP: $TEMPFILE"

wget https://github.com/nbering/terraform-provider-ansible/releases/download/v0.0.2/terraform-provider-ansible-linux_amd64.zip -O $TEMPFILE
mkdir -p ~/.terraform.d/plugins
unzip -d ~/.terraform.d/plugins $TEMPFILE
rm $TEMPFILE

[dnitsch]

#!/usr/bin/env bash
OS_DISTRO="$(echo $1 | tr '[:upper:]' '[:lower:]')"
ARCH_TYPE="$(echo $2 | tr '[:upper:]' '[:lower:]')" 
AcceptedOSArray=("android" "darwin" "dragonfly" "freebsd" "linux" "netbsd" "openbsd" "plan9" "solaris" "windows")
AcceptedArchArray=("arm" "386" "amd64" "arm64" "ppc64" "ppc64le" "mips" "mipsle" "mips64" "mips64le")
TEMPFILE=`mktemp`
E_CODE=0
echo "TEMP: $TEMPFILE"

function checkArrayContains() {
    local arrayVal="$1[@]"
    local value=$2
    local res=false
    for i in "${!arrayVal}"; do 
        if [ "$i" = "$value" ]; then
            res=true
        fi
    done
    echo $res
    return 0
}
if [[ $(checkArrayContains AcceptedOSArray "$OS_DISTRO") ]]; then 
    if [[ $(checkArrayContains AcceptedArchArray "$ARCH_TYPE") ]]; then 
        wget "https://github.com/nbering/terraform-provider-ansible/releases/download/v0.0.2/terraform-provider-ansible-"$OS_DISTRO"_"$ARCH_TYPE".zip" -O $TEMPFILE
        mkdir -p ~/.terraform.d/plugins
        unzip -o -d ~/.terraform.d/plugins $TEMPFILE
        rm -f $TEMPFILE
    else
        echo "ArchTypeNotFound"
        E_CODE=1
    fi
else 
    echo "OSNotFound"
    E_CODE=1
fi
exit $E_CODE

Expanded on the original script, provided the possible OS and Architecture package has been generated this should work can be wrapped in an install script such as

$ ./install-ansible-plugin.sh "$(uname -s)" "$(uname -m)"

[nbering]

@dusannitschneider Thanks, looks helpful...

The biggest challenge I was facing, really, is that different OS Distributions have different commands to run the "real" architecture. For example, a command that works perfectly find to get "amd64" on Linux will return "i386" on macOS.

Given the OS and Architecture, it's not real hard to download and unpack the archive... it's getting to that step that I would like to help people with. So they can simply copy+paste a curl command, piped to bash, and then they're done.

Maybe I've set the goal too close to perfection.

[jtopjian]

The biggest challenge I was facing, really, is that different OS Distributions have different commands to run the "real" architecture.

👍

it's getting to that step that I would like to help people with.

I think it's acceptable to place some responsibility on the user - namely os type and architecture. The latter could even be for edge cases.

What about a script that has a single required argument:

$ ./download.sh mac
$ ./download.sh linux
$ ./download.sh win/windows

Now for 9/10 users, you can safely assume all of those are 64-bit.

But for the users who 32-bit, it's acceptable to assume they are aware of this. So then you could provide options of:

$ ./download.sh win32
$ ./download.sh linux32

And even the arm folks:

 $ ./download.sh linux-arm

The download.sh script itself could have a switch statement for each "user-friendly" argument.

[dnitsch]

@nbering, right - just tried on various VMs, and MacOS is a bit patchy. @jtopjian agreed that most users are covered and should be down to them to specify - I am just mindful of the fact that I will need this across a few orchestration boxes so scripting with some checks seems like a good idea. speaking of which I am just about to try it out - will come back here if any issues.

[nbering]

Agreed on all points. Let me know how your test deployments go.

My intent is to add the install script to the GitHub release, along with a copy-paste one-liner in the README and the release notes. If you get something going well enough, I'll try it out and add it to the docs.

[davisonio]

+1 an install script would be really good! I'm currently experimenting with adding Terraform to my Ansible setup.

[leanderjanssen]

Or maybe you could add the Ansible provider to the list of Terraform Community Providers and let terraform automatically fetch the provider when doing a terraform init. You can request this provider to be added using this request form: Community Provider form

[jtopjian]

Having this provider added as a community provider is certainly worthwhile. However, it will not enable the provider to be automatically downloaded via terraform init. That is only for "core" Terraform modules (basically everything not listed under Community).

[nbering]

Agreed with @jtopjian. It would help people find the project, for certain. But Terraform has (understandably) high standards for taking providers into Core. Hashicorp makes a commitment to help maintain core providers, and they're already pretty overwhelmed with what they have from what I've seen in the GitHub issues.

[rgl]

I believe this can be closed in favor of #29.

[nbering]

Agreed. Closed by #29.