Amazon AWS DevOps Engineer Professional – Configuration Management and Infrastructure Part5

30. Elastic Beanstalk – EB CLI

Okay? So we are going to get started with AWS elastic beanstalk, but we’re not going to use the console for now. We’re going to go a little bit more hands-on and go straight to using the CLI and the ebcli. So the ebcli is a command-line interface that allows you to connect to the elastic beanstalk and interact with it in a much more programmatic way. So to instal it, there are two ways. Either use the ebcli setup scripts from this, and read the documentation to understand how that works, okay? You can also instal the ebcli manually. And if you scroll down, you’ll see the pip instal ebcli upgrade user. So this is what I used when I ran my own thing. So I entered this command into my command line, and it installed ebcli for me. So, hopefully, that works. You know, the emboli is installed, so when you type EB, you get a list of all the commands that are available to you.

Now what I’m going to do is go to my elastic beanstalk directory, and in this directory I have this file, this mg file that we’ll see in a second, and some reference files we’ll use later on in this course. So for the EB file, now we want to be able to create a project, okay? So we’ll make a hello world directory, then go into it, and then we’ll type EB in it to initialize our first elastic beanstalk application. By the way, you should also use a profile.

So for me, I’ll use a profile called AWS DevOps to make sure that I initialized the elastic beanstalk command with the right profile. If you are using the default profile, then this is fine. You don’t need to add this. So let’s go ahead and paste these commands. And here we go. So I’m asked to choose a region. So what is the default region for my project? And I’m in Europe West 1. So I’ll choose number four. And then the application name default is “hello,” because we are in the “hello” directory. So I’ll just keep this as is, and then I’ll select a platform. For this, I’ll choose PHP, so number two. And for a platform version, I’ll choose PHP 7.2, so number one. Also, we are setting up SSH keys for our instances. So I’ll say yes to setting up SSH instance keys, and it detects that I already have a key pair called AWS DevOps. So I’ll go ahead and choose one to use that one.

Here we go. So my EBCL has run. Now let’s look at what happens. So the Hello World directory was being created, and now we have a dot-elastic beanstalk file that has been created for us. And in there, there is a YAML configuration file. So this file, config.yaml, in the elasticbeadstock directory was created by the CLI. And so it shows us that the application name is Hello World. That’s the default, and so on. The key name is aviation. DevOps. And it shows us the region, the default platform, and the profile I’m using for my command. So AWS DevOps So this is good. Now we have created our first project. So why don’t we go ahead and create an index.html file and enter the Hello World text in it? So I can right-click and say, “Okay, index HTML,” and I’ll say “Hello World.” And we’re done. Excellent. After that, I’ll do EB create dev. And this is to create a development environment in my directory. So as soon as I do this, it’s going to zip up the content of my directory, upload this into Elastic Beanstalk, and create my environment. So let’s press Enter and see what happens.

So it says “created application version archive.” So it’s created an archive for me. The archive was then uploaded to S3. Okay. And then we get some information about environmental details. So the app’s name is Hello, EU-One. The deployed version is here, the environment ID is here, the platform I’m using is here, and so on. So we’re now getting status updates directly in my command line. But I could also go to my Web interface and refresh this page. And I should start seeing the Hello World application in here. Yes. And I can click on Devon, and we see that it will take a few minutes to get everything created. As a result, the list of events displayed here is identical to the list of events displayed in my command line. So now what I should do is just wait a little bit until all of this is over. So as we can see now, everything has been successfully launched. And if you look at this log, we saw that a security group was created, a load balancer, another security group, and a launch configuration for our auto-scaling group.

An auto-scaling group was created as well. Some EC instances have been started. Then there was the auto-scaling policy, which included two Clywatch alarms. And then finally, the application is available here. So to access the application, which is very simple, you just type EB open. And this should open a web browser window for you to see the application. So it’s opening on my other monitor, obviously. So let me just switch to that. And here it is. So this says, “Hello, world.” And so our application was deployed. So if we refresh this page, we should also see the Elastic Beanstalk console that says that everything is fine. So let’s have a look at what the EBCL has created for us. It created this application and set it up with a load balancer and auto scaling. So everything is working just fine. And you can switch between the views—the grid view and the table view—by clicking on this little action button right here. Okay? And if we go to our EC-2 service, Maybe we can have a look at a few things that were created, as well as Cloud Watch. Let’s take a look. So we have one instance running in EC2, and that instance is my Elastic Beanstalk instance called Dev End. So this is working; it has security groups.

So let’s go to the security groups, and we can see that we have two security groups that were created. One is for my Elastic Beanstalk environment, and the other is for the ELB. Talking about the ELB, let’s go to load balancers, and we should be able to find our load balancer. Here it is. So this is a load balancer, and it’s a classic load balancer that has been created for us. And we have launch configurations for our Otoscaling group and, finally, our Otis Scaling Group, which is managing our development instance. In terms of instances, we can see one is under management, and for monitoring, we can see all the metrics and the scaling policies. We can see there is a scaling policy that has been created for us, which is simple scaling, and it uses network out as the metric to autoscale. and we’ll see how we can change that later on. Okay, so this is very simple. Then, if we go to Cloud Watch and click on alarms, we should see two alarms created by elastic beanstalk. So, alarms one and two were created, and they serve to autoscale our application. So all in all, the application is working as expected, and we are able to access it using this URL. So we get this. Hello, weld is fine. So excellent. Now let’s go back to the EBCLI and take a look at all the capabilities. So if you type EB, you get the documentation of all the commands you can do.

So you have all these commands right here, and I’m not going to demo them all because there are a lot of them, but you can go and look at the documentation for a few of them. I will show you the most important ones, though. So let’s clear the screen. And now I’m going to type EB status. and EB Status will show you the status of your application. So we can see that the status is ready and the health is green. And this corresponds to our console here. And we go to the dashboard, and it says Health. Okay, so this is our status right now. Then we can have another command called “EB Health.” And if you type it once, it’s going to display the health of your application. So we can see everything is green; we can see all the instances, ID, and so on. And if you type EB Health minus, minus refresh, this window will be refreshed every 10 seconds. So as you can see here, this window is now permanent, and every 10 seconds it will refresh and show me the overall health of all my instances. This screen is equivalent to the one right here called “Health,” which displays the same information and, by the way, also has an auto refresh. So next, I’ll do CTRL-C to exit this, and I’ll clear the screen. We can do EB logs, and EB Lugs will show me the logs of our application as it is being launched. So here we go. We are retrieving the logs. That takes a little bit of time because it probably goes to Cloud Watch. And here we go.

We get some information about all the logs that are happening in our application. So it could be very useful to debug our application without having to SSH into it. So in terms of files we see, we have the VARlog httpd error log, the access log for httpd, and the activity log for Elastic Beanstalk, so how it was being configured, we’ll scroll down, and so on. Okay, so everything looks good, we’ll type Q, and we’re done. This is the exact same screen that you would see if you went into logging here, and you can look at the last 100 lines of logs, for example, and download them as you want it.

But here we get a little bit more information because we have access to more log files using EB logs. So use the ones you want. Next, we want to know how we can deploy changes if we change something. So let’s go to the index of HTML and type “hello, world” v. two. So we re-entered our HTML index into our EB command line. As the names suggest, we’ll type EB deploy and EBdeploy. We’ll create a new application archive that will be uploaded to S3, and then the environment update will be starting.So if we go back to our EBC and go to the dashboard, we should start seeing in a second that a new version is being deployed to our instances. Yes, a new version was deployed to instances, a new application version was deployed, and the update was successful. So let’s click on the domain name again and refresh. Now we have Hello World v. 2.

So the Ebcli was able to upload a new version and update our environment just like that. So the reason I’m showing you this is that if that code was in source control, for example, in code commit, and we had code build or run EB deploy, that could be a way to deploy our applications for us. Now let’s have a look at these versions. So if I go up and click on application versions, we can see that we have two application versions that have been uploaded at different times. So this one was uploaded first; that was the first upload; and this one was uploaded second; that was the second upload. And we can see where they’ve been deployed as well as where they’re employed.

So this version is in use and being worked on. And by the way, if I click here, I’m going to go and download the archive so I can look into what’s in the archive. And if I go to S 3, I can probably find the S buckets where all these archives get uploaded. So elastic beanstalk. West one of the EU. That’s probably going to be the one. Here it is. We have Hello World, and the two application versions have been uploaded by my Ebcli in this one bucket. So this bucket has been created by my EBCL. So that’s about it. If you wanted to terminate the environment, but I’m not going to do this, you would type EBterminate, and that would delete the environment for you. But this is fine. We’ve used the Ebcli to bootstrap our Elastic Beanstalk application, and we’ll be using the Ebcli a lot more to do a lot more things with our application. So I’ll see you in the next class.

31. Elastic Beanstalk – Saved Configurations

So next, we are going to learn how to use Ebcli to create, manage, and share environment configurations. So this is a blog post from the AWS DevOps blog. Again, this is a very helpful resource for your exam. So we’ll go through this blog, but don’t worry, I’m not going to read it out to you. What we’ll do is that we’ll implement this framework so we have an environment, and this environment, as you can see, has a lot of configurations. So all these configurations are here, and maybe I’ll go to a table view now. So all these configurations are here, right? And we’d love to be able to back them up because we need to have some kind of way to have those as code so we can easily reproduce an Elastic Beanstalk configuration in another account in another region or whatever. We’d love to be able to backup our Elastic Beanstalk environment as code.

We could do this by going to cloud formation, and if we went into cloud formation, we would be able to get a confirmation template that was created by Elastic Beanstalk that would contain what we wanted. But this is not very native to Elastic Beanstalk. There is a concept of saved configurations in Elastic Beanstalk, and as you can see, there are currently no saved configurations; however, we will create safe configurations using the Ebcli and use them, and we will see how we can use them to quickly create environments or even reconfigure them directly using code. And this is more evidence of Elastic Beanstalk’s failure. So let’s go back into our code. We’ll go to zeroeb MD, and here is the block-around configuration. So the first command will back up the current development environment configuration.

So let’s go in here and I’ll type “Evconfig save Devon,” which is my environment’s initial configuration, and this is the name we’re going to give to our initial configuration. So press Enter, and this goes ahead and saves a configuration file. So, let’s go into here, and within the Elastic Beanstalk directory, we have saved underscore configurations with an initial configuration CFG ML. So let’s go into this file and see what’s here. So this is a file that has been created by my command line, and so we can see some configuration metadata that we shouldn’t change and some platforms that we’re using. So we’re using PHP 7, 2 running on Amazon Linux, and then some option settings, and all these option settings are How is our Elastic Beanstalk environment configured? So we can see here, for example, that we have a batch size of 30%. When we run a type of update on Elastic Beanstalk, we see that the ELB policies have connection draining enabled true.

We can see that our load balancer, which is a traditional load balancer, has cross-zone enabled true again, and so on. So we can see a lot of different information for the AWS auto-scaling launch configuration. We can see that the instance profile for IAM is the Beanstalk EC 2 role, okay? And the EC2 key name is AWS DevOps. In terms of rolling updates for the auto-scaling policy, we see its type is based on health and that it’s enabled. So that’s a lot of good information, and all our configuration was backed up. So actually, not all our configurations So let’s open this in here and go to configuration. There’s a bunch of configuration here, and that’s actually a lot more than what we backed up, right? This is a lot more configuration than all the things we backed up. It turns out that these are actually the non-default settings that were backed up by Ebcli. Okay? So there are a lot of default settings in here that we did not back up because they’re default, right? So this is why they’re not appearing in our file. Now if we go to Hello World and go to “saved configuration” and refresh this page here, we see that we have an initial configuration that was being created, and the description is “configuration created from the Ebcli using EBconfig save,” which is exactly what we did. So we were able to create our first initial configuration, which is a backup of our environment configuration.

Okay, let’s move on to the next stage. So next, we’d like to set an environment variable in the environment. Okay? So for this, we can use the EB setand command, and then maybe the environment variable is going to be called “enable cool feature equals true.” So let’s run this command in here and directly set the environment variable in ben stalk. Okay, so this is not done in our config file; this is done directly on the environment itself, and therefore we are having an environment update. So let’s go back to our environment, click on Devant, and go to configuration. And now we can see that if we scroll down within the software, we have the environment properties enabled, which is a cool feature that has been created. So I’ll modify this scroll down, and we can see that this environment property value of true was set by the Ebcli. So we are able to apply, for example, environment properties directly using the Ebcli. But wait, there’s more: we can now save the new configuration from the environment.

So if you run an EB config save, and now we name the config “prod,” we’re downloading a new configuration into our directories. So, type: EB configsave Devon config prod, and this will create a new file under Bin stock saveconfig. So let’s go and see that file. And if we go and open up this file right here, we can see that now there is a new line, and I need to find it. And here we go. This is the new line, right here. Elastic Beanstalk is an application environment that has this cool feature enabled. So this is a new line that was inserted directly and saved using the saved configurations again. So, if I return to my Beanstalk environment and navigate to my environment, here is my application. Click on Saved Configuration and reload this page. Unfortunately, it doesn’t refresh. Here we see that we have a product configuration now that was again created using Ebcli. And this will contain the environment variable I have just set.

So now, what if we wanted to go to our environment and go to configuration? And we’re actually not very happy with the auto-scaling rule that we have. So where is it? It is at capacity. I click Modify, and we’re not thrilled that this metric is network out, and we’d prefer to see CPU utilisation instead. Right? So I could go ahead and change there and press Save, but that would be overkill; that would be manual, right? So what I’ll do is just cancel this out, okay? Cancel. What we want to do is change it directly in this configuration file and apply it to the environment. So as such, there is a change that we need to make to this file. And we’ll put this entire block here. So here we go. Prodcfg ML. And in these options settings, I’m going to add a little bit of functionality here. And these are the things that I’ve just added. And so it’s saying the AWS auto-scaling trigger is two. So that means that every time we autoscale up, we should add two instances. The trigger itself is going to be CPU utilisation and its percentage. And the low cutoff is 20%. And for the high alarm, the upper threshold is going to be 50%. So here we’ve just defined an auto-scaling policy. So I’m saving this into my Prodcfg YAML file, and all I need to do is apply this configuration. So I use ebconfig to add Prod and then ebcontact to add Prod here. And this will take my created CFGYAML and simply apply it. So by running this command, EbContact will put up a message if we go to our environment and go to saved configurations.

Now the production configuration has just been updated. So what it did is that it uploaded our configuration and overrode this “Prod” environment name. So a configuration name So now all we need to do is apply this saved configuration, Prod, into our environment. So for this, we’ll scroll down and use ebconfig devnf and then the config name Prod. This is true not only for the local file, but also for the saved configuration that we just uploaded. So let’s run this command copy, and then we’ll paste it. And this should apply the production configuration to the development environment. So as you can see, the environment update is starting. And so let me go into the Beanstalk UI and see if that worked. So I’ll refresh my page, click on device, click on configuration, and then I’ll go to the Capacity tab and modify it. And now we see that we have CPU utilization. It’s a percentage expressed in units. The up threshold is 50%, the scale up increment is two instances, and the lower threshold is 20%. And as such, we’ve been able to apply our extra configuration bits that were added in here. So it moved them around. But the extra bits that were added directly are Elastic Beanstalk environments. So this is the first time you’ll remember that you can use saved configurations to apply configurations to Elastic Beanstalk. And the last thing I want to remember is that these saved configs are incredibly helpful for backing up your Elastic Beanstalk environment and applying it somewhere else. So again, they are in here and have saved configurations. And here we can create them, download them, or even load them into other environments. So if I moved regions, for example, and I went to another of these regions, I could definitely import a saved configuration and very quickly create a new environment from it. So you need to remember this going into the exam as well. This is very helpful for disaster recovery. All right, I will see you in the next lecture.

32. Elastic Beanstalk – .ebextensions for configs

So we have seen one way to apply configurations to our environment using saved configurations. Now there is another way, and this is using the Elastic Beanstalk extensions, or dot EB extensions file. So what we want to do is configure the ASG again using more options and an EB extension file. So let’s go into our code, and we’ll close all these files right here to make it a bit more clear. and I will fold that folder. Okay, I’m going to create a new folder within Hello World and call this one “EB Extensions.” EB Extensions files are files that get run by selecting Beanstalk to configure the environment further. So this is an additional method on top of saved configurations, and they exist within the code. Okay, so let’s go to my reference files, and I’m going to copy this one file right here, auto scaling config, into this directory. So this was from a reference file, and now we have added a zero-one auto scaling configuration.

Now to make this file a bit easier to read, I’m going to go to the bottom line of the VS code and say that this is not plain text; this is actually YAML. And we’ll have a much easier time understanding how to read this file. So this is our first EB extension file that we’re visiting, and we’ll have three in total. So this one is to set options for our environments. As a result, we can use the options underscore settings block to configure our listing bees doc environment. And within it, we have a block for the AWS auto-scaling ASG block, with the min size set to one, the max size set to ten, and the cooldown set to 240. So this is nice. How do we know how to get those in the first place? Well, if we go to the documentation of the last Beanstalk, there is this block called AWS auto Scaling ASG where we can see all the available configurations for our Beanstalk ASG environment. So we have availability zones, cool down zones, and so on, as well as midsize and maximum size. And so this is where I have specified those in this format.

So, hopefully, when this is applied and deployed, it will properly set the odyscaling ASG. We could also do a lot more; there’s not just the ASG that you can configure. You can configure the launch configuration, for example. This will result in a T instance type with two micro. So we’re setting this explicitly, but we could also set an image ID if we wanted to have a custom AMI in our Beanstalk environment. And the reason for having a custom AMI could be to speed up application deployment by installing fewer dependencies in security groups. We could also set them here in the instance IAM profile. If we wanted to override it, we could set it here, and so on. And finally, this is one format of doing things, and I think this is a much clearer type of formatting, but it is possible that you’ll see another format where you have the namespace, the optionname, and the value with an array. And I think this is less clear. And all of this is documented on this page right here, called Option Settings, where it shows you the syntax that I just showed you, but also the syntax that I’m using, which is, I think, a much more intuitive syntax to read. Okay, so all the options for all the environments are on this page. And so, as you can see, there are a lot of namespaces that you can configure. You can configure auto-scaling, ASGlaunch, schedule actions, and initiate a rolling update. I’m not going to read everything out to you, but there are a lot of things in here that you can definitely set as far as options go. So we’ve created our first EB extension file, but how do we go about putting this file into effect for our EB environment? Well, it’s very, very simple. Because it sits within our Hello World folder, it is part of our project next to the index HTML file. And so it sits at the root of our project. Therefore, if we just do a little EBdeploy, this should zip up my entire folder. Yes, it has been created and uploaded to s three.And then the environment update is starting.And hopefully, when the environment update is done, we should start seeing the configuration being applied. So let’s wait a little bit. The environment update is now successful, and if I go to my Elastic Beanstalk dashboard and refresh this page, then I will go to configurations, where it’s loading the settings, and I will go to capacity, click on Modify, and we can see that. Now, our main instance is one, but the maximum is ten, which is what we set, and the scaling cooldown is 240 seconds. That means that everything went well and that our EB extensionsfile option settings were picked up by the listing beanstalk itself after an EB deploy. So that’s really, really positive. Let me just put this back in YAML so you can see it better. So keep the option setting in mind: start with option underscore Settings. It’s a YAML block.

And then we can set a namespace and a key value for the settings you want to set. But we can just set any settings we want that we saw before. This includes not only the ASG, but also the launch configuration, the image ID security group, and, if desired, the ELB. So that’s it; that is one way of setting up configuration. Sorry, another way. So we have safe configurations, and then we have EB extensions. And so one question that can come up is, “Which one takes precedence over the other one?” And so you have this configuration option precedence, and it says that these get applied from highest to lowest. Settings apply directly to the environment. So if you update anything in here, then this will be applied first. Okay? Then the saved configuration has precedence. So any setting that you set in the safe configuration will take precedence. Then comes the configuration file, followed by the EB extension file, and finally the default values. Okay, so that’s all. You now know that it should be console or something along those lines. We apply them directly to the environment. Then there are safe configurations, EBextensions, and finally default values. All right, we need to remember this going into the exam. That’s it. I will see you at the next lecture.

33. Elastic Beanstalk – .ebextensions for resources

So now we have our environment defined. But maybe our application is a little bit more complicated than just “hello, world.” Maybe we need to have a DynamoDB table and an SNS topic as part of our Beanstalk environment. Remember, Beanstalk is just confirmation in the end, or it’s using cloud formation to be managed at the very least. And so we should be able to change this confirmation file and add whatever we want to it. For example, we could use a DynamoDB table and an SNStopic in our application. So this is what we’ll see in this lecture. So let’s go back to our EB extensions. And in the reference file, take the second one called DynamoDB Config and copy and paste it under our EB extensions. Make sure you set the language to YAML so you get formatted highlighting. Okay, so this is the second Extension that we’re seeing in this course.

So we have resources, an AREsource plug, and this is something we are already familiar with. This is something that comes straight out of cloud formation. So you are able to add any kind of resource to your template using this resources block. And so here we have created a DynamoDB table of type DynamoDB table for the properties of the kischema. It has one ID, and it’s a string. And then, for the provision of throughput, we get one read capacity unit and one write capacity unit. So, a very, very simple DynamoDB tablet has been created for us. And because we don’t specify a name here, it’s going to be assigned a random name. Now, for the notification topic, same thing. We just created an SMS topic. And because we don’t specify any properties, it’s going to be assigned a random name. So we’d like to know what the name is at the end of our application because our application needs to be able to use DynamoDB tables and the notification topic. And therefore we could use an output, but this will just be shown as an output in our confirmation stack. Or we can define option settings and define new environment variables here. And that represents the notification topic ARN, the DynamoDBtable, ARN, or name, sorry, and the region. S

o, this is a strange kind of syntax, but keep it in mind. not necessarily remember it, but just know that it exists. So, the notification topic is in reference to the notification topic. So it looks like this, but it’s surrounded by back ticks and quotes. And so we have the same for DynamoDB tables. And we could even use the AWS region, which is a pseudo parameter, as an environment variable to inform our application in which AWS region it is operating. Okay, so let’s go ahead and just run this to see what happens. So we’ll do EB deploy, and this should apply and create for us a DynamoDB table and an SNS topic. So let’s wait a little bit. And our environmental update is now successful. So, if we go in here, we won’t see any DynamoDB tables or SNS topics. But if we go to cloud formation, refresh the stack, and we’ll refresh the outputs, as we can see now, we have a notification topic, ARN, which is the output that was created by our EB extensions. And if we go to resources, we should see that we have somewhere in here a DynamoDB table. So I’m just going to search for it. So DynamoDB.

So we have a DynamoDB table, which is right here, and that was created for us. And it has this very long random name, okay? And here we also have a SNS topic. So here is a notification topic that was created by, again, our cloud formation stack. So if you go to SNS, we should be able to see that topic. Here we go. That was created by an elastic beanstalk. So what we can see here is that we have applied a B extension file, which has provided an extension to our cloud formation template, which has created for us the resources that we wanted and the outputs, if we generated any outputs. So keep in mind that some environmental variables were also used. So if I go to configuration and click on “modify here,” I have to refresh this page because otherwise it doesn’t pick up the new configuration. So click on “Modify” again and scroll down; we can see that. Now we have three new environment variables: the AWS region, the DynamoDB table, and the notification topic. But here, the values are not resolved yet. They will be resolved by the EC’s two instances at runtime, dynamically. So how do we verify this? Well, let’s go into our EC2 instance.

So for this, let’s go into services and type EC 2. Here we go. And within our EC2 instance, we have one running instance. Here it is. So if you try to connect using EC2 instance Connect, it’s not going to work because it’s running an AMI that doesn’t have this yet because it’s the beanstalk AMI. So you see, it’s the beanstalk, AMI. As a result, it lacks the EC to instance connect feature. For now, maybe you’ll have it when you watch this video. But instead, I’ll do a good old-fashioned SSH like we used to. So I’m going to go in here, clear, and I’m going to run my SSH command to SSH onto my instance. Okay? So I’m on my instance, and it says “elastic beanstalk.” So it welcomes me with a nice little thing. And what I would like to do is make sure that these environment variables right here are actually being resolved, okay? So for this, there is a command called Optivinstall Bingetconfig Environment, and this will display all the environment variables for me. So let’s do pseudo su.Now that we’re root, we’ll run this command, and we won’t see much. So I’ll do yum instal JQ and say yes, it’s going to be better. So I’ll run the exact same command again and pipe this into JQ to have this display. That’s JSON. And here we go. We can see from our environment that the AWSregion is EU West, and the notification topic displays the entire ARN. And the DynamoDB table name is again in here. So that’s really helpful because here we see that they were just references, but dynamically, when deployed onto the instance, they’ve been resolved to their actual names. So you could do something like minus K and notification topic to get just the notification topic. So, oops, only the notification topic is right here. So you can query for a specific type of environment variable, and I’ll clear this, and you could also query for option settings. So using this command, get config, you can query for the option settings, and here we can see what was set in our container in terms of memory limit and so on, the host manager, and the application environments. So you have a lot of options with the get conflict command. And this is very helpful when you want to debug within an instance and see the types of environment variables, for example, or conflict options that were applied to the instance. Okay, so that’s very cool. We’ve seen our second way of doing configurations, and this is the time to allocate resources for a DynamoDBtable and an SMS topic and also pass themon as environment variables to our instance. I will see you at the next lecture.

34. Elastic Beanstalk – RDS in or out of environment?

So, just a quick architectural discussion here. So, we have defined a DynamoDB table and an SMStopic within our code using the EBIT Extensions file. So that means that this DynamoDB table and this notification topic are completely tied to our environment. So we have a development environment with a DynamoDB table and SNS topic. And if we were to create another environment and apply the SIM settings, then it would have its own DynamoDB table and SNS topic, right? And this is fine, but that also means that if I go ahead and delete this environment, this will delete this confirmation stack. And so any resources that are in this cloud formation stack—so, we have 17 resources in this cloud formation stack—will be deleted. So, this is quite bad if you’re in production, and if your DynamoDB table is something that should hold value regardless, or if your application is running, then you cannot create it as part of your environment because otherwise it will be deleted if you delete your environment. So here, if you need to have an external DynamoDB table, you cannot define it in your EBN Extensions file because this will be deleted. And this is tied to your environment. So how can you go around it? Well, what you could do is create a table externally.

So maybe using another confirmation template or manually And I’ll call this my external table. And we’ll have an ID, which will be a string. This is great. And I’ll use a one-to-one provision capacity. So, one and one, and then click Create. Here we go. So, we have my external table. And so now, if we want our development environment to reference my external table directly, the trick we could do is go to the configuration, and you could set this configuration however you want using option settings or EB Extensions. But at the end of the day, what you would want is for your DynamoDB table to have this value, not my external table instead.

And so this will help your application know that it should look up this externally created table that you created. And so this is a way to manage resources that need to outlive your Elastic Beanstalk environments. So you could have DynamoDB tables. But also, a very popular resource that needs to outlive your environment is usually an RDS database. So the exam will ask you, “Hey, should I have my RDS database as part of my Elastic Beanstalk environment, or should I have it externally and reference it using an environment property?” Well, that only depends on whether you want the lifecycle of your RDS database to be tied to the lifecycle of your Beanstalk environment or not. and that depends on the question they ask you. So, that’s it for this architectural question, but hopefully the point makes a lot of sense, and I will see you in the next lecture.