Advanced Networking with Adobe Experience Manager as a Cloud Service

Transcript

Hello, my name is Carlos Sanchez and I’m here with Alvaro Soring and we’re going to talk to you about advanced networking on Adobe Experience Manager as a cloud service. This is something that would be useful to you especially if you are migrating from on-premise into the cloud service. Let’s say you want to connect to existing services using non-standard ports or using different ports than the default ones, whether you need a dedicated IP to connect to these external services or on-premise or whether you want to connect using VPN to services both on-premise or in another cloud provider. So we’re going to talk about three, these three big separate use cases. First one, flexible port egress. By default on AM cloud service, only the port 80 and 443 are allowed. With flexible port egress, we allow you to connect to any other port or service and for an example is connecting to an SMTP server or sending email, connecting to a database, anything like that. The second case would be to have a dedicated egress IP because by default egress IP on cloud service are shared across multiple customers. So in this case, we would give you a dedicated IP and for instance, if you want to connect to external service that is limited on the firewall by policy and you have to have an IP that is allowed on the firewall, in this case you would get this dedicated IP. And this IP would be unique for each AM program. So you can have multiple environments and they would all be sharing the same IP under the same program. The third case would be for a virtual private network to connect to an on-premise or other cloud services that are behind the VPN. Also to connect from the VPN to AM and this VPN case covers the dedicated egress IP case. Each of them covers the previous one. So both with dedicated egress IP and with VPN, you will get flexible port egress. So these are the three big options you will have and these will be available in the next days. Just keep an eye on the announcements. How do we configure all this? The three options have our common setup which is this onboarding process. You onboard the program on the advanced networking functionality. This will set up the infrastructure that is required and by itself doesn’t change any of the environments. Each of your environments is working on them and that should change the environment within the configuration. The next option is the environment would be running. So you could have environments running in different regions but advanced networking infrastructure production so it has lower latency. And this onboarding operation of the whole program is a one-time only thing. It can take some time up to an hour. And then you need to wait for the onboarding of the program to finish before you can enable any of the environments. The behavior to connect to these external services is going to be the same across all the options. For HTTP traffic, we forward this by using an HTTP pre-proxy and for other protocols we set up imports and you have to send the traffic explicitly to this proxy. So the default traffic that is not going through these proxies is more optimized. So advanced networking so you know should only be used when needed. If you don’t have the need to have a dedicated egress IP or to open extra ports, there’s no need to do any of this and just use the defaults. On the first case, flexible port egress. This would be and this is very similar to all the cases. You can onboard the program by using the cloud manager API. You would do a post, you would choose a region. These region identifiers come from another API in cloud manager where you can get all the regions that are available and the kind would be flexible port egress. So this would be the onboarding of the program. For the environment onboarding, it’s again very similar for all the cases. And flexible port egress, you call the cloud manager API and you define what are the destination, host and ports that you want to connect to and also you define a port that you would connect from. So this part would need to be unique. So let’s say you want to connect to smtp.example.com on port 587. You would just make up a source port in the 50,000 range and you would say 50587 and that would be the port that you would use to connect to. So to enable these port forwards, you would call this API, networking environment API and you would pass a number of ports with different destinations. So in this case smtp, MySQL and you would set different origin ports for each of them. For HTTP traffic, you don’t need to do any of this. You just use these variables to set up an HTTP and HTTPS proxy and then when you configure your HTTP client and then any port will be available for you to use. For non HTTP, as I show in the previous API, you would connect to the AM proxy host environment variable that would give you the proxy host name and then the port would be the one that you set in port origin. So this is a tunnel that would, you would send the traffic to this host and that origin port and that traffic would go to the destination that you set like MySQL.example.com 3306. For example, with MySQL, if you use the driver, the gtbc driver, you would just compose the URL that you are connecting to getting this AM proxy host system variable and the port. For the second option, dedicated digress IP, same thing as before. You can onboard the program, choosing the region and the kind that we dedicated digress IP and then you could, to know what would be that dedicated digress that you’re getting, you can query a DNS server and it will be this program ID.example.atvmcloud.com that would give you the actual IP that would be just dedicated for this program. For each environment that you would onboard, it’s a bit different with flexible port. For HTTP and HTTPS protocol traffic, AM is automatically configured to transparently send all this HTTP traffic through the proxy. So before you would have to send traffic explicitly through the proxy, in this case, all the traffic is going through the proxy and then getting the dedicated digress IP. You can also set exceptions for specific hosts, setting the non-proxy host variables in a very similar way that you would set up a proxy on Java. And for non HTTP protocols, it’s the same configuration as in the previous section. So as in the previous section, you can set port forward, as NTP, MySQL, and you can also now send non-proxy hosts, hosts that you don’t want traffic to go through the proxy because you don’t need a dedicated digress IP. And this way it would go direct to the destination. Once the environment is onboarded, the proxy is automatically configured using a standard JVM system properties, HTTP proxy host, HTTP non-proxy host. When you use third-party clients, just make sure that they use the standard system properties or manually configure them. Non-proxy host includes some internal defaults and you can also add your own, like a sample.com or a start.example.com subdomains. The traffic that matches this non-proxy host is going to go directly and is not going to get this dedicated digress IP. So it would be able to go through the default egress of the cluster where your environment is running. And traffic from the dispatcher, you have to explicitly configure. You can also do it, configure it to use the dedicated egress IP. And the proxy variables that you would set are this AMHDB proxy host and HTTP proxy port. An example would be this. If you want to connect to example.com slash some path from the dispatcher, you would set the proxy remote directive with this value and then just use proxy pass and proxy pass reverse as you would configure the dispatcher anyway. The third option, the VPN, is the most complex of them. You can onboard the programs again using this cloud manager API, same API, with a few different extra parameters to configure how the VPN is connected. So on one hand, space, this would be a 6-bit CDAR. So it’s a set of 64 IPs that is on your customer, on the customer space. So this would be a private IP that is part of your network, of your private network. You can configure the DNS resolvers to use the ones that resolve your internal DNS names. The gateway address would be the VPN device. So the IP of your VPN device, the customer VPN device. The gateway address space, this would be the IP ranges that are routed through the VPN. So this basically would be all the IP ranges of your private network. Share key is the secret. An APSIC policy is a set of algorithms and parameters that you need to set to match our side of the VPN with your side of the VPN. So the post would be like this, address space, DNS, and then you would have a connection entry with just one connection that says what is the gateway address, address space. And the last part of the APSIC policy, in the reference documentation, you will find all the possible options. But the APSIC policy is a set of algorithms that would be provided by either your network team or whoever set up the VPN device on your side. On VPN, there’s three APS that are interesting. First is a dedicated public egress IP, like in the previous case, you get a dedicated egress IP. All the traffic that is going to the internet goes out with this public egress and with the same setup as dedicated egress IP, the previous section. For the traffic that is going to your customer network, you’re getting a private egress IP. And also, for networking, maybe you want to filter on your site what is the IP of our VPN gateway, so you only allow that IP. You can also get that querying DNS name. For HTTPS, it’s the same as with dedicated egress IP. You have also the option to do non-proxy hosts. And then the traffic will split based on whether the destination address matches the VPN address range. So either the traffic is going to go to the public internet or it’s going to go to your VPN based on that address range. And you can also configure egress traffic coming from your VPN into EM. This reduces the number of hops that are between your VPN and the CDN and allows you to block public traffic. So you could have internet sites and things like this. And you would have to configure the DNS on your site to point to this private IP. And on the CDN, the traffic would show up as coming from your dedicated IP. And then you could do allow list, block list, and things like that based on those IPs to allow traffic from the internet. And some best practices that are good to know, not just for advanced networking, but for every use case on the cloud. The full AM architecture is redundant, fault tolerant. But you need to know that network connections can be dropped at any time for multiple reasons. For instance, an upgrade could trigger a pause in many of the components and that connection is dropped. Or there’s a fail over because a component fails or availability is going down. Then you wouldn’t see a downtime, but some connections make it drop as things move from one place to another. And so connections can fail for certain periods of time. Make sure that you always retry networking failures to provide a resilient service, maybe degrade performance instead of erroring or retry with exponential backoffs to avoid overloading the systems. Long running connections such as database connections can be dropped. You have options like on JDBC, you can validate connection pools to set them up as there’s a test on borrow property that will validate these long running connections before getting them from the pool and then make sure that they’re always ready. And now Alvaro is going to do a demo. Thank you, Carlos. Yeah, just give me a second. I’m going to try to share my screen. Okay. Yeah, so I’m going to do a demo, a quick demo about how to use this API, this common AR API for advanced networking. Right, so I’m going to start by showing how to create a dedicated egress IP. We are going to start by querying the Cloud Manager API for knowing the current status of the advanced networking features for a program. So we have to send a GET request to this URL in Cloud Manager and Cloud Manager is going to return a JSON where we can see that the network infrastructure is empty. Okay, so at that moment we can create a new network infra and the only thing that we have to do is to send a POST to that URL and to specify a region and kind dedicated egress IP. So once we send this request, Cloud Manager is going to return a message that says that the status of this network infra is being created. Right, we can see the timestamp and some other details there. So we should poll the Cloud Manager API, checking the status and seeing if the status changes from creating to ready. So we need to see if the status changes from creating to ready. So at some moment it’s going to change. Right, so for dedicated egress IP it’s going to take maybe 5-15 minutes, something in that range, and then it’s going to return the status ready. We can see that what kind is dedicated egress IP and we can see in the timestamps that it has taken something like five minutes or so. So at this moment we have to use this dedicated egress IP in some of the environments. We can start by querying the status for an environment. We can send a GET request to this URL Cloud Manager is going to return a JSON saying that the advanced networking features are not enabled. Advanced networking enabled equal to. Right, so for using advanced networking in this environment we just have to send a PUT request to the same URL using a setting advanced networking enabled true. Right, so we can send this payload and that’s going to start, as Carlos described, a proxy that is going to send all the HTTP and traffic, but we can also create these tunnels for some particular destination. Right, so for this port in the region it’s going to send traffic to that host name and that port. So we can send traffic for some specific services like SMTP or a database connection or something like that. That’s going to map a local port to our remote port. Right, so once we do that we send this PUT request to the Cloud Manager API and Cloud Manager is going to return a JSON that says that the AM instance is being updated. Okay, so for VPN things are very similar. We can start by querying the current status for a program. We can send a GET request to the same URL and then we can get the list of network infra for this program. We currently support only one network infra per program where the network infra is empty and then we can create a new VPN setup for this program. It’s a post message to that URL and the payload is going to be a bit more complicated. It has more parameters, right, so we have to specify things like the region and kind is going to be VPN. The address space is, as Carlos described, a range of IP addresses for creating a proxy in our infrastructure. Then we can also specify some DNS resolvers that are going to be used for resolving DNS names. The other important parameter is the list of VPN connections. We currently support only one connection at this moment and we have to specify the remote endpoint, an IP address or a DNS name where the other side of the VPN connection is there. The address space is the range of IP addresses that are going to be reachable through this VPN connection. The shared key and the IPsec policies are details for the VPN connection that must also be provided, right. So once we send this post message to the API, it’s going to return a message saying status creating and it’s going to take a while. The VPN infrastructure can take something like 30 minutes or 30-45 minutes to be created. So after some time, we can pull the API and then the status is going to be different. It’s going to be, we can send the GET request to this URL and then the status is going to be ready, right. So it’s there, status ready and at that moment we can activate this VPN connection for all the environments that we want to use this VPN connection. We can send, we can first check the current status of the advanced networking for this environment by doing a GET. This URL, it’s going to return it’s not enabled, it’s advanced networking enabled, false, right. So and then for enabling the advanced networking features for this environment, we just have to put a message where we say advanced networking enabled true. That’s the only thing that we are going to do in this case, we are not going to create specific channels or anything like that. So we can just put a message that says and it’s a put message and when we send that, a cloud manager is going to return a message saying okay I am updating AEM. AEM is going to be redeployed and it’s going to be redeployed with the VPN connection enabled. And that’s it, it’s a very easy to use API. If you guys have any questions you can hopefully answer any of your questions in the chat. Thank you. Yeah can you unshare now? Okay let’s see. Okay. So to sum up, it’s a lot to condense in this short session but you can use advanced networking when you need to connect to services in ports not open by default which are 80 and 443. When you need to connect to services, start by using a dedicated ingress IP because there’s a firewall that needs to be by policy just limited not open to the whole internet, anything like that. When you need to connect to services behind the VPN, no matter whether they are on-premise or they’re in another cloud provider or when you need to limit ingress connections for to those coming from the VPN only like an internet site. So this is what advanced networking does and we hope it’s useful. It’s going to be available in the next days and you can ask us questions. I pasted the links on the chat and I’m gonna be here to answer. So let me see if there is something else here. But yeah feel free to ask us any questions later after the session in those links that I pasted and then we can try to answer them. Thank you very much.