Technical onboarding - Fastly
- Topics:
- Cloud
CREATED FOR:
- Intermediate
- Developer
Learn about the cloud usage of Fastly for Adobe Commerce.
Who is this video for?
- Website managers
- Commerce architects
- Owners of e-commerce website
Video content
Transcript
This is Russell with Adobe, and this is your Adobe Commerce Cloud hardware handoff. Today we’re going to be going over Fastly. So Fastly is a CDN. It is a tool that is used to help with the delivery of some of your assets like images to make sure that they load as fast as possible. It also does extend the Adobe Commerce full page cache, and the benefits are these Fastly nodes live all over the world, and what happens is when a request comes in from a browser, it finds these closer servers that are physically located nearby this request, and then it serves up those content, like for example an image, faster because it’s retrieving it from literally a closer proximity than your application servers, which could be thousands of miles away. The nice thing about Fastly and the way it works with Adobe Commerce Cloud is that there’s nothing to configure inside of Fastly itself. Everything is managed through the Adobe Commerce admin panel, and also a nice feature is you have the same flexibility to use APIs to manage your VCL snippets. A very nice and probably the feature that you’re going to utilize right away is the image optimization. What this means is that it will take your images and it will retrieve that original copy on the first request from the application servers, but then every time someone is asking for another image, instead of going all the way back to your servers, it’s going to utilize its CDN, its content delivery network, to transform and return this image that they’re trying to ask for. It works on all of the standard web formats like PNG and JPEG and GIF. Optimization and the management of customizations to Fastly is managed through VCLs. What’s great about the way Adobe Commerce Cloud has integrated with Fastly is you can actually create your snippets inside of the Commerce admin, or once again, you can use the APIs to manage them manually. Fastly also does provide a WAF, a Web Application Firewall, and the purpose of this is this will help make sure that incoming requests don’t violate any of their predefined rules that have been configured for Adobe Commerce that are known to be exploits in the OWASP top 10. It will take different requests and it will flat out reject them if they violate one of their rules. It is part of our PCI obligation. Once again, there’s nothing to be managed or configured inside of Fastly. Shielding is handled on behalf of you and then all you do is through configuration is you make some changes in your Commerce admin to configure it. There also is one additional benefit, which is origin shielding. The purpose of this is to force all requests through Fastly and then prohibit requests directly to your application servers. If they do, it will get blocked. A few extra features that I haven’t mentioned so far is their forced TLS, which means when that’s enabled, any HTTP request will be upgraded to HTTPS. You can do access control list, which means you can block requests from certain countries or IP addresses, and you can manage that through the admin. You can create custom maintenance pages. You can do basic authentication, which means if you’re maybe pre-live and you only want people with provided credentials to access your site, you could do that through Fastly, and then it will require a username and password to get to your website. Once again, you could do geo IP, which means you can take somebody who may be calling in from Ireland and take them to your Ireland store or somebody who’s making a request in from the US, make sure that they’re at least starting on the US store, and then let them choose the store code from there. But yeah, geo IP is a really good tool and it is used quite often. The first thing that you’ll do when you get access to your Adobe Commerce Cloud project and you get access to your site is configure Fastly. This is mainly because as soon as you introduce third party code or custom code, it’s a little bit harder to debug where an issue might reside. So if you get access to your site, you get access to your code, you log into the admin and you configure Fastly first, it helps make sure that the site in its out of the box state works as expected. And that way, every time you introduce new code and new third party modules, you can help pinpoint where an issue might come from. If you wait till the middle of your project, sometimes the debugging process can be a lot harder. So do it first, and I’m going to quickly walk you through where this is in the Commerce admin. So once you log into your site, the way to get to the configuration side is to go to doors, configuration, and then you’re going to go down to advanced and then system. Under the full page cache section, you’re going to change it from built in cache to the Fastly CDN. And then what you’re going to need is the service ID and the API token. And those are provided for you on your Commerce servers. And the reason they do this is they’re configured for your site and your site only. And the reason why they put them on there is that if you have access to your site and the servers, then you should have the authority to then enter these credentials onto your server. So that’s why we won’t hand them through email or anything else. You’ll have to log into your server and grab these tokens. And the way you do that is you go to your terminal and you can log in with SSH. And I’m going to use the Adobe Commerce Cloud CLI tool, but you can use SFTP if you wanted to. You could use just regular SSH. But for this one, I’m going to use the Cloud CLI and I’m going to log in. And normally you would get the different credentials. There’ll be a separate set of credentials on the production server, and then there’ll be a separate set of credentials for the staging server. So that way you don’t contaminate each pool. They’ll separate for you. For my particular instance, I just have a master branch, a production branch. But once again, make sure that you do this for your staging and then also for your production. And there’s two separate credentials that you’ll grab. So for this one, we’ll log into our production and then we’re going to go to the directory of MNT and then the directory of shared. And then inside of there, you’re going to find a file called Fastly underscore tokens dot TXT. And so if you look at it, this is going to have the different pieces of information that you’re going to need. So what you’re particularly interested in is the service ID and then the API token. So you’ll copy those out and then you’re going to add the service ID there and then the token. And then the other value that you see on there, this is actually the ID for your project. So once you’re done, you’re going to go back to your admin. You’re going to enter those two values. You can hit test credentials and that will just do a really quick test to make sure that they’re valid. And then if you’re all good, the last step that you’ll have to do is upload to Fastly. But that’s quickly how you find and leverage those tokens. The reason why you’re going to be doing this is once again, your project needs to leverage Fastly for its DNS and SSL records. Once again, you’re going to do this. There’s two separate credentials, one for staging and one for production, and then you’re going to validate them. And those are your three simple steps to get your project configured. For more very detailed documentation, I go to Experience League and read the tutorials and the documents for how to configure, use, do custom VCLs, manage them through APIs. It’s very well documented. As far as your DNS records, you will receive an email from your technical account team and they will provide your Acme challenge. They will help provide the CNAME information to use. They’ll also help with your SendGrid setup. Some of these things you need to do right away, and then some of these things are going to be expected to be delayed until you launch. So for example, setting your subdomain of www and your Apex domain to Fastly, you obviously don’t want to do that right away because that would divert all the traffic to your site that’s being developed. So you’ll want to defer that until your day of launch. But your other two, so like MCStaging and MCProd, those are some domains that you’ll have to create in your DNS management tool. And the purpose of this is those will be your URLs that you’ll use while you’re doing the development of your site, getting ready for your launch. This way you can leverage the staging environment and the production environment all the way up through all of your final QA, all of your UAT. You can leverage those actual environments for the testing and the prep so that way when you do go live, you’re already on the existing hardware and then all you’re doing at the day of launch is making a configuration change inside your commerce admin as well as making the Apex domain and the www subdomain pointing to Fastly. It makes it for the transition to go as fast as possible. Managing the commerce admin panel, once again, there’s only one thing that you have to do and that is change your configuration value from being the built-in cache to Fastly CDN. Once you’ve done that and once again, you’ve logged into the server, you’ve retrieved the service ID and the tokens and you’ve enabled it, all you have to do then is upload it to Fastly and that first VCL will be saved and your site will start leveraging. The last thing that we’re going to talk about is verifying that Fastly is working for each domain. So before you’re live, you’ll want to do this on your MC staging domain, subdomain, and then you’ll also your mcprod.whateverexample.com. The purpose of this is you want to make sure that Fastly is configured correctly for both of those so that way when you’re doing your QA and your UAT, everything will be as expected and will be what will be used as you’re getting ready for live and obviously for the go live and the post go live. The form is fairly simple. All you have to do is enter your URL that you want to test. So for example, it would be like mcprod.example.com or mcstaging.example.com. You’ll grab the service ID from your configuration and if you don’t have it handy, you could always log into your server. Remember, you’re going into that mount shared directory and looking for a file called fastly underscore tokens dot txt. You’ll grab the service ID and you’ll put it in there and hit check. And if all of the boxes come back green, that means everything is fully enabled and you are ready to do your testing. If any of them are red, there usually is a tool tip that explains what it is complaining and then you can either go into your commerce ad and make the appropriate changes or read the documentation that it refers to to help you understand what you need to change. So that’s your Adobe Commerce Cloud hardware handoff with regards to Fastly. Please don’t forget to go to Experience League, continue your education and your learning on Adobe Commerce and have a great day.
Experience League documentation and Fastly Adobe Commerce checker 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