Environment variables with Adobe Experience Manager as a Cloud Service

Transcript

Welcome to today’s session on environment variables. Environment variables in AEM as a cloud service. We hope that all of you and yours are staying safe and healthy. We are delighted that you’re able to join us virtually today. My name is Shankari. I’m a senior product manager for AEM. I’ve been with Adobe for three years, and I was a product manager for a few years. I’ve been with Adobe for three years, and I will be one of your presenters today. Presenting with me is my colleague, Raul. Please introduce yourself. Hi, I’m Raul Huda. I’m with Adobe for more than 10 years, and I’m happy to be here with you. Without further ado, let’s get right to it. At any point during today’s presentation, you can double click on your screen to zoom in to get a closer view of the content being presented. At the end of today’s session, you have three key takeaways. One, adaptive code is easy to maintain. Environment variables can make your development process better by allowing you to vary the behavior of your code based on the context. More importantly, you can do this by setting up the configuration one time and updating it as necessary in one location. Two, environment variables enable improved security by following industry best practices. The separation of code from configuration not only boosts the security of your application. Additionally, no code changes or deployments need to occur to take effect. And three, expensive mistakes can be avoided by following best practices that environment variables enable. A mistake that all of us have probably made in our development careers is working on a testing environment with the configuration of the production environment or vice versa. For example, the outgoing mail server that was configured on production sneaks in after a restore or backup to a local environment. Setting out test emails to your customers is, well, something that is better avoided. We are super excited about today’s session and hope you get as much out of it as we do. A quick look at today’s agenda. We’ll do a quick overview, followed by the most exciting part, the demo. So be sure to stay and watch this. We will leave time for Q&A, of course. Before delving into the details here, an important requirement in order to use environment variables in cloud service is to set up your cloud manager integration on Adobe IOCLI. The cloud manager plugin for Adobe IOCLI will come in very handy to interact with the same underlying capabilities. It’s a fully programmatic fashion. In addition to enabling capabilities like setting up pipeline variables and environment variables, it also enables things such as starting pipelines and a host of other capabilities. AEM cloud service environment variables are truly simple to use. They can be broadly viewed as pipeline variables and standard environment variables. If the code you want to change the behavior of is your build process, you use a pipeline variable. For example, if build time JavaScript minification is being done through a tool like Gulp, there may be a desire to use a different minification when building for a dev environment as opposed to building for a stage or production. Another example would be if on the development environment, you might want to disable caching. If the code is running inside AEM, you would use standard environment variables, and these are used in OSGI configuration. For example, storing passwords or other sensitive information in your version controlled system like Git is never a good idea. So instead of setting the password directly in the configuration files in your code base, you can use a reference to an environment variable. The what you want to change determines the variable type, and in this example, the type would be secret. Now you’ll get to see some of these examples in action in the part you’ve all been waiting for, the demo. I’d like to now hand it over to Raul. Thank you Shankari. To use environment variables, you need three important things. First, you need to be able to access the Cloud Manager APIs. Adobe provides a standardized way to access the Adobe services by creating API integration in the Adobe Developer Console. Second, while you can access directly the Cloud Manager API, there is an easier way to do that by using the Adobe IOCLI tool together with its Cloud Manager plugin. And of course, the third one, your code needs to be modified to take advantage of the environment variables. Now let’s dive into the pipeline variable use case where we want to change the build behavior based on the pipeline variables. So in order to set up a pipeline variable, you need to create an Adobe IOC console integration. To be able to create such an integration, you need to be either a system administrator in your IMS organization or to have the developer role inside it. Make sure you are not confusing the Adobe developer role with the Cloud Manager role. Those are two different things. I already have this integration created. It shows all the necessary details that you will need in order to configure either the CLI tool or be able to access the API directly. You would need things like the client IDs, client secrets, technical account IDs, and all that. But before using the tool, let’s set up some context. I have here a standard program having three different environments, a dev, a stage, and a production. For the purpose of this demo, I want to change the behavior of the code-only pipeline. The code-only pipeline is just building the code and then it stops. I’ve already configured my IOC CLI tool. Like I mentioned, in order to use it, you will need to configure it by setting these values into a config.json. I’ve also set up my default program just to not set it for every command. The third part is having your code be updated to make use of the pipeline variables. To do that, I’ve added the Maven property, the node build command, which by default uses the build as a command. And I’ve created the custom profile, which gets activated automatically once this node build command environment is set. And of course, when the execution is being run, the value of the node build command property will be used in order to execute the npm run command. What I want to achieve here is for my front-end application, I want to change how the npm behaves. So in the package.json file, besides the standard build command, I’ve created a new one, the build dev command, which in this case is just adding another message, like this is the dev build. But of course, here your limit is your imagination and required needs on what you want to achieve. Like Shankari mentioned, maybe you want to disable minification of the script or include some other tools that need to be run. Now let’s move to the IO console. Like I said, this is already configured. So first I want to be able to identify my code-only pipeline. For that, I’m going to use the list pipeline command in order to see which is my build-only pipeline. I see that I identify my pipeline, and now I’m looking whether I’m having some variable set on this particular pipeline. Shouldn’t be any. Yeah, there isn’t any. And now I’m using the set variable command from IO console to set the node build command, the pipeline variable, to the build dev command. This will set the pipeline variable and will list the existing values for this pipeline. Now that this is set, I can go to Cloud Manager and I could start the build-only pipeline. But since this is taking a little longer than we have, I already have here two builds. One build is without the environment variable being set and the other with that one. So first I’m looking at the one without the environment variable. I’m going to download the log file for this one. I’m going to search for the npm run build command. I’m seeing that this one is running the npm run build. Now if I go to the other one, this is a build that was run together with the variable set. If I’m going to download the log for this build, and this is searching for maybe npm run build. And I can see here that I see my command that echoed this is a dev build command. Now that we have modified the behavior for our pipeline execution, let’s move to the next step, in which we want to change the application behavior by changing the environment variable. To use standard environment variables, this is supported via OHAI configuration. There are three types of OHAI variables that can be used. The most common ones are the inline values, which are values that are hardcoded into the OHAI configuration and they can be stored in Git without any problems. The environment specific values are values that can vary based on for development environments. It is recommended that you should use this one only for development environment and not for stage and prod because the main reason being that for stage and prod, you always want to keep that values in Git as opposed to being changed via variables. And of course, the third type are the environment secrets, which should not be stored in Git for any type of environment, whether it’s a dev or prod or a stage. So in order to set up the environment variables, you can use the same integration and the CLI configuration that was used previously for the pipeline variables. You don’t need to create a new one specifically for this one. For setting the… I have here three configurations for a simple service that I’m using that is basically trying to connect to an external service, HTTP bin, which is just basically an echo service returning you back all the headers and URLs that was used to make that. So I have here my variables. One is the environment variables for the dev environment, which I’m changing the endpoint. And also I’m setting here a special authentication header for which is a secret, and it will be stored as a secret. Now I want to be able to set these variables for my dev environment. So first, I’m going to list the environments to figure out which is the dev one. I’m seeing here which is the dev, and now I’m going to set the endpoint environment variable to the location of the service, having dev at the end to make sure that this is the one that I want. So I’m going to set it. Okay, now you can see here that I also have authentication token set and also the endpoint. Assuming that right now I want to set my authentication token as well as a secret, I’m using s, dash s to specify that this is a secret. Now if I’m trying to do it right now, I’m going to see that it’s not possible to set it. This is because you cannot set an environment variable while the environment is being updated. Either due to a pipeline execution that is deploying new code on that one, or you just have a variable that is being updated on the environment and it’s doing changes there. You can only set the environment variables if the status is in red. Now in order to validate that, I’ve created a simple servlet just for demo purposes. It’s calling this server, HTTP bin, which is a public one. So if I’m running my servlet, I am going to see that the authorization header is using the value that I set, dev token, and also the endpoint, which is the URL here, it’s the one having dev. This concludes my demo. So I’m handing back to you Shankari. Thank you. Thank you, Rahul. That was a great demo and such a powerful way to show how environment variables on cloud service can be put into action. With that, I’d like to recap the three key takeaways from today’s session. By using environment variables, you need to worry about setup and configuration of your application codebase just once. Two, you can avoid putting sensitive information in your version control by separating code from configuration. And three, you can vary the behavior on testing or dev environments versus production or stage environments and avoid expensive or embarrassing mistakes. With that, I’d like to open the session up for Q&A. So I see a question here, Rahul. Can we set an environment variable prior to code deploy? Yes, you can set the variable as long as the environment is in the proper state, and it will be used during the next… It will be used when a new deploy is being done. And also, of course, it’s going to be used if the code is already there automatically. Secret variable. What means in detail with regarding security? It means that first you are not keeping your secret values in clear in your Git where multiple developers have access to that one. And also, the secret is being stored in a specialized service internally in Cloud Manager and only passed to environment where it’s also kept secret in using the proper services where the environment gets… where your code gets deployed. Or oj configs, can we use secret storage solutions? To use the secret interpolation, currently you need to set the secret as an environment variable. If you are using it in a different way, you will have to add the code for that one. Yes, if you want to test it, of course, before using Cloud Manager to do the deploy, you can use the AM Cloud SDK to test your changes locally and make sure that when you are setting the proper environment like that, they are going to use what values you expect from that one. Using the AM Cloud SDK should be the way how you are adding support for it because it gives you a much faster development cycle. If you want to set multiple variables at once, it’s possible to set it via the CLI tool and just pass a JSON file having all the variables and it will be applied all at once. Because otherwise, as you saw, in case you want to set one by one, you will have to wait for each environment to be actually applied on the environment and that might take a few minutes. Of course, it’s possible if you set an environment variable to also delete it. Variables are set and stored for any update that needs to be deleted prior or release. Only if you don’t need them. Otherwise, they are always used inside the application. And of course, if you are setting environment variables and then you are not using them, you should only delete them only after the code that is not using them has been deployed and validated. Otherwise, if you want to roll back, it might imply that you need to set them again. To change the value of a variable, just set it to a new value and it will be applied. There is no version for the configuration for the environment variables. The latest version will be the one that is going to be used. There was a question that I didn’t answer related to the local SDK. To test passwords or tokens with the local SDK, you need to, since you are running locally, you need to set up a special Java property pointing to a file that contains the secret. The information, the link on how to do that, I think it should be also part of the references on this specification, but I think, let me see if I can find it. Can we change environment variables at one time when I am running? If your environment is running, it means that AM is running. So if you are setting the environment, of course it will apply, but it means that maybe you want to change it without AM being restarted to use it. Then no, it will need to wait for that variable to be applied again. IO CLI is just an open source tool that can be used to access not only Cloud Manager, which is just one of the services exposed via the Adobe Developer Console, but all the others that have plugins for that. This is the standard way of interacting with Adobe services. It’s not linked to Cloud Manager. But of course, in order to access Cloud Manager, you will need to have your license. Thank you.