I've got a Liberty Profile app that I am building/deploying with the devops pipeline, and I don't see any mechanism for determining the current build that is running. I've dumped all the environment vars, and nothing appears to indicate the build number.
Is the value someplace I am just not finding or is it really just not available?
Build and Deploy Jobs in Bluemix DevOps Services offer and environment variable called: BUILD_NUMBER. This variable is not propagated automatically to Bluemix runtimes.
Perhaps in the deploy script, you can add a Cloud Foundry environment variable associated to your app. Something like:
cf set-env "${CF_APP}" BUILD_NUMBER "${BUILD_NUMBER}"
so you will have such info accessible from the running code.
Hope it helps!
Related
If we are deploying a basic WebApp / WebApi, both these tasks from Microsoft appear to do the same thing - deploy to an appservice.
AzureWebAppV1
AzureRmWebAppDeploymentV4
How do you choose which one to use in a new YAML release pipeline? I just want to make sure I am using the version that is most future-proof - I have 25 release pipelines and don't want to have to re-do them unless necessary.
The way the help is written, hard to compare feature to feature to spot the key "must-haves". Some Microsoft online examples use both. Both are still marked as "In Development" in the readme and both are >1 year old since last check in.
The simplest way to deploy to an Azure Web App is to use the Azure Web App Deploy (AzureWebApp) task.
By default, your deployment happens to the root application in the Azure Web App. You can deploy to a specific virtual application by using the VirtualApplication property of the AzureRmWebAppDeployment task.
Azure App Service Deploy task allows users to modify configuration settings in configuration files (*.config files) inside web packages and XML parameters files (parameters.xml), based on the stage name specified.
Just my two cents, but I just noticed Web App Deploy takes much less time than Service App Deploy. I was wondering how come a simple zip deploy (Service App Deploy) can take so long. So I looked around and found there's also that Web App Deploy, so I tested it.
My project (React/Next small sized app) normally takes 6-10 min to deploy with Azure Service App Deploy (v4). With Azure Web App Deploy (v1) it took a little more than a minute. Wow.
I'm just starting to play with the IBM cloud offering. I've built a simple flask app and am trying to deployt it via a toolchain. When I run my toolchain the app deploys successfully, however I can't access the url.
I am looking at the deployment logs and have a couple of questions.
First, I see this:
2020-12-24T15:00:39.66+0000 [APP/PROC/WEB/0] OUT * Environment: production
But the environment I thought I was deploying to was dev. How do I change the environment I expect the toolchain to deploy to?
I'm assuming that the url that shows up in the log output should be accessible, but it isn't.
My manifest has random-route: true defined. How do I check that the url in the logs is available and pointing to my deployed cf app??
Thanks for any help and Happy Holidays!
Have you checked the app using the cloud console ui at https://cloud.ibm.com There should be a link to the app url.
It is possible to differentiate between def and prod via environment variables. I believe you can pass environment variables via the manifest file. You can sent via ibmcloud cf set-env and then ibmcloud cf restage.
So the reason my app was failing was I was missing a couple of items/components
First, from the code I needed these lines in my python.
port = int(os.getenv('PORT', 5000))
if __name__ == '__main__':
app.run(debug=True, host='0.0.0.0', port=port)
The cloud foundry deployment maps the external facing url to your app.
In order to do that it needs to know what port to use and that first snippet sets it to the port defined as an environment variable (IBM Cloud defines this) or port 5000 if the variable is not set.
The second snippet is the standard script special variable evaluation and execution control mechanism.
I didn't have this or the app.run call.
adding these allowed me to get the app running by pushing it from my machine locally. Now that i have it deploying successfully, I'll start working on getting it to deploy via a toolchain.
I figured all of this out by reviewing this tutorial I found on github and comparing what they were doing and what I was doing.
https://github.com/IBM-Cloud/get-started-python
Lastly, to see how the app has been mapped go the cloud foundry section of the ui and select the app. From there you can look at the logs and they show how the app maps in the url resource access history. That being said, fundamentally this wasn't going to help me solve my problem as it was related to my source code, not the actual route mapping.
Seems your toolchain has environment variable set which you can change by setting the following:
ibmcloud cf env-set flask_app Environment development
It can also be set via mainfest.yml file as shown below:
env:
env_name: development
URL is given on the UI that you may refer. Other way to check the URL is to look for the route so you may use
ibmcloud cf app flask_app
If you see any issues in accessing the app using route so it means there is some problem with the app causing this to happen.
I am currently provisioning a new resource group using Azure Arm template and Powershell
New-AzureRmResourceGroupDeployment
The resource group template defines all the resources.
A couple of different app service resources are provisioned as part of this resource group. Each app service resource has app settings.
The resource group gets provisioned sucessfully including its app service but from time to time, the app settings are missing on the newly provisioned app service. I am required to teardown and re-create the resource group and it works fine.
When the custom app settings are missing then, in the portal, there is only one app setting visible: WEBSITE_NODE_DEFAULT_VERSION
Any pointers for how I can troubleshoot this so the environment provisioning process is consistent?
Are you using the -DeploymentDebugLogLevel parameter in the PowerShell command you are using for the deployment? There are different values for that parameter that control how much debugging information you get. I have used it in the past to help troubleshoot IaaS deployments using ARM templates. More information is here: https://azure.microsoft.com/en-us/blog/debugging-arm-template-deployments/
Does the app have slots? If yes, are the appsettings tied to specific slots? When we perform a swap slot, then the appsettings can disappear, if the settings are slot specific. Also, are you performing an Incremental upgrade or Complete? As Tom commented, sharing the template will help in understanding whats going on.
We have now come to the point in our Service Fabric application development where we need to add a custom parameter that can be overridden at run time (as described in https://azure.microsoft.com/en-us/documentation/articles/service-fabric-manage-multiple-environment-app-configuration/). We're still in the development stage...no azure production environment, yet, so this question mainly concerns running the service fabric cluster from visual studio or thru a powershell script in a VM. I know that Deploy-FabricApplication.ps1 is ran during debug and per its usage instructions in that file I can override custom parameters. However, I can't seem to figure out where I do that in Visual Studio so that when different developers start a debug session they can set the custom parameter value to whatever makes sense in their dev environment. Any ideas? We have a task to research how to better handle secrets storage but we're not quite there, yet.
You can add multiple publish profiles (optionally without checking them in). One for every developer if needed.
For secrets: you can encrypt settings and/or use Azure Key Vault combined with a Service Principal, similar to what is shown here.
I am currently tinkering with Cloud Foundry. I understand the basic principles of the tool but can't find what cf push actually does to a manifest file.
Does it read the file just once or is it stored as a static file with the application?
Also, is it possible to retrieve a manifest from a deployed app?
The cf push command reads the manifest file and uses the attribute values (instances, memory, disk etc) for the current deployment. The manifest helps to automate the app deployment. It can also be used for deploying multiple applications at once. As stated here: https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html, when you deploy an application for the first time, Cloud Foundry reads the variables described in the environment block of the manifest, and adds them to the environment of the container where the application is deployed. When your app is running, your environment variables can change depending on your setting. For example, if you have an auto-scaler, it could have increased/decreased your no. of instances/memory/disk (environment variables). If that is the case, when you stop and then restart an application, its environment variables persist.
The manifest file is read only when the "cf push" command is executed. As stated in the Cloud Foundry Documentation (https://docs.cloudfoundry.org/devguide/deploy-apps/prepare-to-deploy.html#exclude), the manifest file is just read and not actually stored as a file, hence it could not be accessed for a deployed app. However, if the purpose for accessing your manifest is to read your current environment setting, it can be accessed through the Cloud Foundry API's Get App Summary (or) Get detailed stats for a STARTED App: https://apidocs.cloudfoundry.org/234/