A colleague developed a terraform script that used version 0.14.x of Terraform. He uses a local Cloud Shell while I use the Cloud Shell in the GCP console.
The GCP console reports the terraform version as being 0.12.x.
How do you update the version to the latest? I tried following the Debian instructions from the Hashicorp web site and now, if I try to follow them again, I am told I have version 0.14.x installed but if I type terraform --version I still see 0.12.x.
What am I missing?
You can switch between versions of TF by typing the command tfswitch on your terminal.
or else what you can is to remove the old version from path
you can get the current version path from which terraform
you can remove the old release from the old path and add the binary to same place in GCP Cloud CLI.
You can directly download the zip into GCP cloud CLI using :
wget https://releases.hashicorp.com/terraform/0.14.7/terraform_0.14.7_linux_amd64.zip
unzip and set the binary at the same path
Related
The hosts on github action are in US only and I need to run my tests from EU region. I created AWS ec2 with eu region and connect my github workflow to the instance. I installed python3.10 on my ec2 :
enter image description here
but when I try to run the test I get this error:
Version 3.10.0 was not found in the local cache
Error: Version 3.10.0 with arch x64 not found
The list of all available versions can be found here: https://raw.githubusercontent.com/actions/python-versions/main/versions-manifest.json
Do any one know what should I do ?
try to change version , without any version reinstall python. didn't work for me...
I am getting the following error when running terraform init on my Macbook. Can someone please help?
Provider registry.terraform.io/hashicorp/template v2.2.0 does not have a package available for your current platform, darwin_arm64.
My terraform is version is 1.1.4.
The hashicorp/template plugin became obsolete (in favor of the built-in templatefile function) some time before Apple introduced its new Apple Silicon platform. The only releases available for that provider are those which were published before that platform existed.
To move forward on Apple Silicon hardware, you'll have two main options:
Ideally, plan to migrate away from the obsolete provider and use the built-in template function instead. That function is built in to Terraform itself, and so doesn't need any external provider to work. It is also more capable than the old template_file data source in that templatefile can accept template variables of any type, whereas template_file only supports strings.
If you are not yet ready to migrate away from that provider then you may instead prefer to use the darwin_amd64 version of Terraform under Rosetta 2 emulation. If you use a Terraform CLI release for darwin_amd64 then it will in turn install darwin_amd64 provider packages, and so you'll be able to use the final release v2.2.0 of the template provider.
Terraform is not officially supported under Rosetta 2, so how well this will work will depend on how complete Apple's emulation layer is, but it can hopefully serve as a short-term workaround until you're ready to stop using this obsolete provider.
I solved it by using the tfenv package, which can build a specific Terraform version adapted to the platform architecture.
I ran the following to install a version that works under my M1 Macbook (version 1.3.3 in my case):
brew uninstall terraform
brew install tfenv
TFENV_ARCH=amd64 tfenv install 1.3.3
tfenv use 1.3.3
For me building "hashicorp/template" from the source was the solution. I was using terragrunt.
git clone https://github.com/hashicorp/terraform-provider-template.git
cd terraform-provider-template
go build
move the binary to terraform plugins directory. You can create the directory if the plugin's directory does not exist.
mv terraform-provider-template ~/.terraform.d/plugins/registry.terraform.io/hashicorp/template/2.2.0/darwin_arm64/terraform-provider-template
Set execution permission to the terraform-provider-template binary file.
chmod +x ~/.terraform.d/plugins/registry.terraform.io/hashicorp/template/2.2.0/darwin_arm64/terraform-provider-template
terraform init or terragrunt init from your project folder.
I am following this tutorial on how to create a HTML web app within Azure
When I enter the az webapp up command I receive the error:
Could not auto-detect the runtime stack of your app, see 'https://go.microsoft.com/fwlink/?linkid=2109470' for more information
The version of Azure CLI I'm running is:
azure-cli 2.0.78 *
command-modules-nspkg 2.0.3
core 2.0.78 *
nspkg 3.0.4
telemetry 1.0.4
Extensions:
azure-devops 0.16.0
Any help with this would be much appriciated!
I ran into the same problem and it looks like there is a problem with static html site. Today version 2.0.79 was released and it supports an --html flag. At least my app is now working.
The tutorial guide you use the Azure Cloud Shell to deploy it, but as you know the CLI in the Cloud Shell is version 2.0.78 and it does not support the parameter --html and you also cannot upgrade the CLI in the Cloud Shell.
The parameter now is only supported in version 2.0.79. So the solution is to install the CLI in your own environment. Follow the steps here to install the CLI then it will work well with the parameter --html.
It just seems the issue is with the current directory from which the command is run.
It probably needs to detect files specific to a run-time stack before uploading the app; Such files, like the 'package.json' file for Node.js would on exist within the app's directory. So please try 'cd' into the app's directory
I am trying to run using pygal libray to show graph in AWS lambda.But this error is shown, even I have already installed lxml.deployment_package
my_source_code
import_error
It's because lxml contains binary pre-compiled libraries that it uses. When you install lxml locally on your Windows machine, you install a Windows-compatible version of it. However this is not compatible with the Lambda execution environment which is Linux based.
So you have to create a Lambda compatible deployment package. You have couple of options doing so. You can use sam build --use-container, you can build the libraries in a Docker environment and then zip those, etc. See this answer as well.
My current platform version is: Node.js running on 64bit Amazon Linux/2.0.1
Which support following NodeJS versions: 0.12.6, 0.10.39, 0.10.38, 0.10.31, 0.8.28
I am looking a way to upgrade the NodeJS version: 4.x.x which seems to be available in platform version: Node.js running on 64bit Amazon Linux/3.1.0
but when I am upgrading it. it's says
How can I select the allowed version as it's not available.
Any Help,
Thanks,
P.S
1. Already tried via save / load configurations. Unable to find any option there.
2. Don't want to do setup it from the scratch for now.
First, ensure that you have tested the changes adequately before deploying to production. After that, you can:
Note the name of the Platform ARN/Solution Stack you want to upgrade to.
Perform eb init --region REGION_NAME and pick the application and environment you are working on
Perform eb config. This opens your environment's configuration in an editor. Change the value of the PlatformArn to the one you noted above in step 1.
Also in the editor, find the option setting aws:elasticbeanstalk:container:nodejs. Change the NodeVersion to 6.9.1 or one that the error message above suggests.
Save and quit.
After the configuration is complete:
Perform eb status to verify that your environment is using the upgraded Solution Stack.
You can clone the existing environment to a new one, using a different platform version.
In the Actions menu, select "Clone with the latest platform".
That opens a new page where you can select from available OS/nodejs versions.
Once you are satisfied with the new environment, you can swap URLs with the old one in order to replace it. After that, you can remove the older env.
This has happened a few times before when Amazon releases new Environments and they do not include versions in common between the environments. The solution is to set value for nodejs version to an empty string which means to use the latest version. It could break your app, but you can make a clone with latest platform and switch to desired version of nodejs later. So run this command to do that:
aws elasticbeanstalk update-environment --region "your region" --application-name "your app" --environment-name "your env" --option-settings "OptionName=NodeVersion,Namespace=aws:elasticbeanstalk:container:nodejs,Value=''"