Closed nbering closed 4 years ago
#!/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)"
@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.
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.
@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.
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.
+1 an install script would be really good! I'm currently experimenting with adding Terraform to my Ansible setup.
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
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).
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.
I believe this can be closed in favor of #29.
Agreed. Closed by #29.
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:
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):