In Azure Iot edge deployment template json, I see a variables named MODULES.SampleModule or MODULES.SampleModule.json. An example is at this link. There is JSON schema at iotedge repository. But I am not able to find a reference documentation for the variables that could be used in an azure deployment template json.
From where is the variable MODULES.SampleModule populated?
Is there a reference documentation for azure deployment template variables?
For the deployment template, every variable must be in this syntax ${var_name}.
When running the deployment file generation, the variables will be replace by the host environment variable with the same name.
For example, I have ${CONTAINER_REGISTRY_USERNAME} and ${CONTAINER_REGISTRY_PASSWORD} in my deployment.template.json. On my host machine I have, CONTAINER_REGISTRY_USERNAME and CONTAINER_REGISTRY_PASSWORD set has environment variable. When the task is run, they are replaced.
To make it work in a pipeline, you must add the environnement variables on the host machine. In AzureDevOps, you must create a library (https://learn.microsoft.com/en-us/azure/devops/pipelines/library/variable-groups?view=azure-devops&tabs=yaml).
In your pipeline, you can use this task to make the generation :
- task: AzureIoTEdge#2
displayName: 'Generate deployment manifest - amd64'
inputs:
action: 'Generate deployment manifest'
templateFilePath: 'EdgeModule/deployment.template.json'
defaultPlatform: 'amd64'
deploymentManifestOutputPath: '$(System.DefaultWorkingDirectory)/config/deployment-amd64.json'
validateGeneratedDeploymentManifest: 'true'
fillRegistryCredential: 'true'
I have a github project with a default iotedge template including a full pipeline for unit test, code coverage, build and push image, generate deployment manifest and deploy to iothub.
https://github.com/MaxThom/IoTEdgeModule-Template
Good luck :)
This project was built with the Visual Studio Code IoT Edge extension (https://marketplace.visualstudio.com/items?itemName=vsciot-vscode.azure-iot-tools). It is the template that is used to generate the actual IoT Edge deployment file. When the extension creates the deployment file from this template it will substitute those variables with the required values. This is an implementation detail that is not exposed and thus undocumented.
Related
I've been trying to find a way to access the scheme name from a Run Script build phase. I'm writing a CLI command that updates a user's Xcode project so I don't have the luxury of tinkering with the Xcode user interface. I have been using Cocoapod's Xcodeproj dependency to update the build settings.
The first port of call is Xcode's build settings environment variables which do not contain the scheme. See here: https://developer.apple.com/documentation/xcode/build-settings-reference
I thought I would be able to do it programmatically via Xcodeproj dependency, but it appears the environment variables it sets are for the run-time application, not the build settings environment variables. See here: https://www.rubydoc.info/gems/xcodeproj/Xcodeproj/XCScheme/EnvironmentVariables
Apple's documentation on schemes makes no suggestion for this predicament:
https://developer.apple.com/documentation/xcode/customizing-the-build-schemes-for-a-project
QUESTION:
I was wondering if anyone had any suggestions for obtaining the scheme name that is running from a Run Script build phase? Some setting I could apply programmatically using Xcodeproj or another tool to configure the project that could pull the scheme name as a value at build time?
I don't want to hardcode the value into the script as this would require generating multiple scripts in the build phases for each scheme.
A scheme isn't really a "thing"; it is merely a unification of several other aspects of the build operation. The particular aspect you probably want is the configuration, which is available as the CONFIGURATION build environment variable. In a bash script, for example, you can include a line such as
if [ $CONFIGURATION = "MyWonderfulConfiguration" ]; then
You can create configurations in the Project editor, and you can tie each scheme to its own configuration in the Scheme editor.
Configuration:
Scheme:
Environment variables:
I'm wondering if it's possible to feed arguments, or environment variables into a Dockerfile used by AppEngine (flex environment).
I'd like to use this command:
COPY ${STAGE}/keycloak-files/realm-config/* /opt/jboss/keycloak/realm-config/
"STAGE" variable would allow to select the origin (I have a "staging" and "production" directory, containing different configurations).
I've got two different app.yml files, one for each environment, but from what I read online, environment variables are not exposed to the Dockerfile at build time.
People suggest to pass arguments to accomplish the task. But how would that be possible with appengine, where we don't execute the docker build command directly?
As #DamPlz said there is not a straight way to pass env variables from the app.yaml to the Dockerfile during the deployment phase . Here are some workarounds that I could think of:
One option could be to create the variable in the Dockerfile directly and if you want to change it each time at runtime you can use a placeholder value and have a script update the value of the variable before running “gcloud app deploy”.
On the other hand you could use build triggers in Google Cloud Registry to modify it in the Docker image using user-defined substitutions.
I am new to using serverless framework ,I wanted to create three different environments dev,Qa,prod. How do i create in single serverless.yml file ? The provider is AWS.
You can pass a stage CLI option that can be interpolated wherever needed in your serverless.yml file. For example, take the following CLI command:
serverless --stage dev deploy
This can be accessed in serverless.yml with ${opt:stage}. I usually include this under provider:
provider:
stage: ${opt:stage}
Then you can get the value of the stage option anywhere in serverless.yml using ${self:provider.stage}.
When lambdas are deployed, their ARNs are automatically constructed with prefixes of the service name (as defined by the service key in serverless.yml), the stage, and the lambda name, like the following:
arn:aws:lambda:us-east-1:010101010101:function:myservice-dev-mylambdaname
So you can simply run the deploy CLI command for the other two stages/environments you want, and you'll have a set of separate resources for each environment.
I am currently doing a POC on Jenkins pipeline to figure out how to configure my product in a CI environment. The requirements of the pipeline are:
Checkout code from SVN
Compile the program
Deploy to a predefined location on the server
Change DB configurations (& maybe even other configs not identified yet) to point to the appropriate DB
Execute the program
Execute QA process to validate the output
I am currently having difficulty in achieving Point 4 above. All DB-related configurations reside in a database.xml file per program & a program can connect to 1 or more DBs.
Given that developers are free to check-in any DB configurations, I would still like my CI environment to point to a predefined DB to test against. I am unsure on how to dynamically change these configuration files to achieve this.
Please let me know if there are standard methods that others are also using to achieve the same.
TIA
Some approaches:
Properties using Advanced Platforms
Use some web platform like :
zookeeper
http://www.therore.net/java/2015/05/03/distributed-configuration-with-zookeeper-curator-and-spring-cloud-config.html
Spring Cloud
https://www.baeldung.com/spring-cloud-configuration
This is a java spring framework functionality in wich you can create properties file with configurations and configure your applications to read them.
magi-properties-management
This is a java web system in which you can create environments and any key:value in each one. You just need configure your application in any language to read this values.
cyber-properties-management
This is a nodejs application that allows you to store properties files (.properties .yml or .json) and then just consume them as rest endpoint from your applications.
With this approaches , when a change of configurations is required, you just need update the value in the system and restart your application. It is even possible a hot reload in java applications.
Properties from Environment variables
You can export your key:value properties as environment vars before starting the application :
export DATABASE_HOST=10.100.200.300
export LOG_DIR_LOCATION=/logs
And read it after after the application has started:
Java >> System.getEnv("DATABASE_HOST");
node.js >> process.evn.LOG_DIR_LOCATION
php >> getenv('DATABASE_HOST')
Properties from SCM
Create some svn repositoty called development-configurations
Upload your database.xml with development values
In your application, put a database.xml with dummy values : localhost, etc
Create a jenkins job and put the environment as an argument.
In the same job download svn source code of your application.
download svn repository called $environment-configurations. $environment will be your argument
replace the database.xml inside of your application with database.xml of $environment-configurations repository.
Just create another repositories for testing, uat and production. Job must be receive environment as an argument to choose the right database.xml
Properties from Database
Modify your applications to read configurations from some database instead of xml file
Properties from File System
Modify your application to read an external database.xml instead of the database.xml inside of your source code. With this approach you just need put the database.xml in some path of your server and delete it from your application source code.
Note
You can use these approaches not only for backend apps. You can use them for frontends applications:
Devops Variable Substitution for Frontend js applications
We are moving from tfs 2012 to tfs 2018 and converting our XAML build templates to 2015.
For the most part, using the default build template TfvcTemplate12 work well. However when a project references the build number, it fails.
One example is when we use the windows service publish task.
<WindowsServicePublishTask Publish="$(DeployFileService)" ServiceDisplayName="$(ServiceDisplayName)" Destinations="$(ServiceDestinations)" SourcePath="$(OutDir)" BuildNumber="$(BuildNumber)" CreateDropFolder="$(CreateDropFolder)" />
I get the following error
The "WindowsServicePublishTask" task was not given a value for the required parameter "BuildNumber".
How can I reference the build number using TfvcTemplate12?
You are using the wrong environment variables. For XAML build:
TF_BUILD_BUILDNUMBER The build number of the build. For example: CIBuild_20130613.6.
More details please refer TF_BUILD environment variables
You can use the TF_BUILD environment variables to get key bits of data that you need for your build process logic. For example, you can get the path to the source folder or the path to the folder that contains the outputs you want to drop.
TF_BUILD environment variables
Use environment variables in MSBuild
Use environment variables in programs or scripts
Use environment variables in a custom build process
A sample of adding something like the following options to the MSBuild arguments:
/p:DeployOnBuild=true;DeployMethod=Package /p:DefaultPackageOutputDir=”$(TF_BUILD_BINARIESDIRECTORY)”\WebPackage