Technical onboarding - Configuration and debugging
- Topics:
- Cloud
CREATED FOR:
- Intermediate
- Developer
Learn about the key Yaml files used in Adobe Commerce Cloud for configuration across different environments, the tools available for validating and optimizing these configurations, and the process for debugging and logging. Understand the importance of environment-specific settings, how to use EC tools and Quality Patches, and the role of New Relic in log aggregation. Gain insights into remote debugging with Xdebug and the necessity of managing logs across multiple app servers.
Who is this video for?
- DevOp engineers
- Commerce architects
- Backend developers
Video content
Transcript
This is Russell with Adobe, and this is your Adobe Commerce hardware handoff. We’re going to be talking about configuration and debugging.
There’s four files that are responsible for Adobe Commerce Cloud, and these four unique YAML files are the ones that drive different areas of configuration. Some of these are available from your integration environment into your staging, into your production, and will cascade throughout. Some of them will only apply in integration, and then one particular file, the .magento.env.yaml, those would be environment-specific, so those would have to be modified in each environment because they will only apply to that environment’s level. So things to note are the .magento.app.yaml. Those are going to be application settings, so things like your build hooks, your cronch, your PHP versions, those are all things that you can configure and manipulate on that particular file.
The .env, the .magento.env.yaml, once again, those are just environment-level settings, so you’d only need to modify those per environment. So for example, you could have different values for staging as you do in production. The .magento.routes.yaml, that’s going to be for the primary route of your site, and then any custom redirects. Most of the time, redirects aren’t applied there. You’ll either apply those in Fastly or you’ll do it through the Commerce application, but just know that this is available, and for more information on that, please visit Experience League.
The .magento.services.yaml, these are going to be specific to just the integration level that they’ll be applied to. Anything else, staging and production does require a support ticket, but that’s where you would modify, for example, your Redis version or Elasti version. As far as the php.ini, you can do some core PHP settings there, and they will be applied on every deployment. The same thing with the config.php, you can do some configuration changes there, but once again, those aren’t heavily used, but just know that they are available.
And the last one is the custom file called magento-vars.php. You’ll use the same file called magento-vars.php. You’ll use this if you have multiple websites, and this also is covered in Experience League. We do have a couple of Adobe Commerce provided tools. One is the ECE tools, and then the other one is the quality patches. For the ECE tools, this is a command line tool to help you do a few different configuration validations to make sure that your YAMLs are configured to the optimal settings. It’s a really great tool that has a lot of features and functionality. Please make sure that you go to the corresponding Experience League pages to learn more about that. The quality patches tool is used to look up known issues and patches that have been generated. These will be unique and very specific to certain instances and certain scenarios, but once a customer or a set of customers has experienced it, the same scenario, the core development team will create a patch and make it available as a quality patch, and then some of these will eventually get merged into the next one of the future releases, so that way that issue will be mitigated from that point on. Another tool that is available for all of the Adobe Commerce cloud environments, integration, staging, and production, is Xdebug. This is a great tool. This does allow for remote debugging. When you’re debugging your integration environment, you can create the changes necessary in the app.yaml file, and then you can do your own debugging without any customer support, but for staging and production, you do need to create a support request ticket, and they will enable Xdebug. At that point, once you get notified that it’s been enabled, you’ll be able to do your SSH tunneling and enable Xdebug, and you can either run it through the browser or you can do it via command line. One thing to note, if you do enable Xdebug on staging or production, make sure that you create a follow-up ticket in order to get it disabled. There is a performance impact if you leave it enabled, so by disabling it, you will definitely help in any performance issues that might escalate out of having Xdebug enabled. Xdebug is fairly well documented, especially the steps on how to configure it, do your SSH tunneling, and then how to do your remote debugging. It is fairly well documented in Experience League. As far as researching and leveraging your log files, there are logs that are generated on each individual app server, so you’ll have three different app servers or more, and every one of those logs are independent from one another. So if you’re trying to track down maybe an IP address that’s being malicious, it isn’t good enough just to log into one app server because that request from that same IP might have hit your other two app servers. So if you’re going to be doing any log aggregation, the best place to do that is going to be in New Relic, but you do have the capacity and the ability to log into each individual app server and review those logs independently, and then you can grep them and do whatever you want to do at that point. But just know that the aggregation of all of your logs happens in New Relic. That does not happen on the individual nodes. They remain isolated from one another. The only exception of that is the cron and the post deploy logs. Those are only occurring on node number one, so if you are looking specifically at that, you can log into node number one to review those logs. Once again, you can get all this information in New Relic if you’re looking for an aggregate.
Another thing to note for where the logs are located, if it’s an integration or any other feature branch that you create, they’re always going to be in var log or app var log. For production and staging, the pattern is basically the same. It’s going to be var log platform, and then the folder will be your project ID. In this example, it might be abc123, and then for staging, it always has a suffix of underscore stg. It would be slash var slash log slash platform slash abc123 underscore stg. As far as New Relic, New Relic does contain all of your aggregated logs, so anything that’s coming from your commerce application and Fastly all stream there. There is a very short delay when the logs are pushed there and then readable in the application, but it’s not very long, and it is pretty close to real time. If you do really need real time, then you’re just going to have to SSH into each individual server, and then you’re going to have to do a lot of stuff on each individual server and pull the logs in there. If it is a Fastly log that you’re interested in, we do not have direct access to Fastly, so your only view into that will be through New Relic. Both of these topics are covered quite nicely and experience-ly, so you can go there and do a search and be able to find the appropriate documentation.
That’s all we have for this topic. Thank you for listening, and please continue your journey in learning about the Adobe Commerce product, and have a great day.
Experience League documentation mentioned in the video
Additional related tutorials
Commerce
- Commerce Tutorials
- Adobe Commerce Cloud
- Getting Started
- Global Reference Architecture
- Help and support
- Edge Delivery Services
- Webinars and events
- GraphQL and REST
- Adobe Developer App Builder
- Store Administration
- Customer Management
- Catalog Management
- Content Management
- Marketing Tools
- Orders and Fulfillment
- B2B for Adobe Commerce
- Tools and External services
- Commerce Intelligence
- Commerce Upgrades
- Back-end Development
- Native Front-end Luma Development
- Headless Architecture