hi welcome back in part three of this
series we will focus on the architecture
and configuration
of the application you launched in the
first video and customized in the second
so the assumptions then are that you
launched the application in video one
that you customized it in video 2 and
that you also accessed the application
source
in github as described in that second
video
as a reminder though you can find the
application source
at aws labs on github at this point
we've seen our application as it exists
in the management console
we've also opened the app up and used it
and saw that it stores information about
customers
who want to know when our product
launches that data goes in dynamodb
and the application also uses the simple
notification service
to send you an email when a new customer
signs up now let's address the
cliffhanger we left you with at the end
of the second video
where did the dynamodb table and the sns
topic come from
and how did your application
configuration learn about them
let's talk about where the table and
topic come from first
so if you do nothing else an elastic
beanstalk environment looks like this
it's automatically load balanced and the
server capacity automatically scales
it can also store log files for you in
s3 and provides a monitoring and metrics
dashboard
your beanstalk environment doesn't
automatically come with a dynamodb table
or an sns topic we'll call this a
resource customization
you can easily customize resources in
elastic beanstalk
with configuration files a configuration
file is
a file with a dot config extension am i
blowing your mind here yet
it is yaml formatted it declares other
aws resources
you want created along with your
application and you save the
configuration file in a folder
named eb extensions at the top level
of your application let's look at the
configuration
file for our sample application here see
here's my eb
extensions folder it's at the top level
of my app i have one dot config file
setup.config you can have multiple
config files that do different things
they're processed in alphabetical order
based on file name
the resources key is where we go to
define resources our first resource is
called startup signups table
and we see its type is a dynamodb table
the properties then tell
dynamodb how the table should be created
we've just provisioned one unit of read
and write capacity for this table
we would of course increase these values
to accommodate more load
before deploying to production and we
can make these changes just like we make
code changes
update the value in the file and upload
the changed application to elastic
beanstalk
beanstalk will take care of modifying
the properties of the table
if it already exists so it makes it
really simple to scale our dynamodb
table performance out or in
as needed we create the s s topic
similarly
and use its properties to subscribe an
administrator's email address
to be notified when a message is
published
okay so it's great that we can use the
resources block and tell elastic bean
stock the things it should create
for our application now we need to tell
our application
where those things are via its
configuration
the flask framework makes it easy to
load configuration values from various
places
in our case we'd like to create a file
that has our app config
in key equals value format in addition
to creating resources
our elastic beanstalk.config files let
us customize things on our servers
including creating files in this files
block we tell
eb to create a file at var app
app.config we tell it the file
permissions and we specify the contents
of the file
in this example the first line of var
app app.config
will be aws underscore region equals
and the ref syntax dynamically injects
the current region we're running in
for example us-west-one
the second line has the value startup
underscore sign-up underscore table and
the ref value injects the name of the
dynamodb table
created above in the resources section
the order here doesn't matter
the files block could come before
resources elastic beanstalk is smart
enough to infer dependencies
and will do things in the correct order
for you automatically
finally we can use the setup.config file
to inject environment variables into our
eb
servers flask allows you to indicate the
application config file
to load based on an environment variable
so we set the app
underscore config environment var to
equal slash var app.config
flask also supports debugging which is
something you definitely
do not want turned on in production we
expose flask debugging
as an environment variable and tell our
application.pi
to enable debug mode based on that
variable
this lets us turn debugging on and off
from the elastic bean stock management
console very cool
it's easy to get your app up and running
with elastic beanstalk but you're still
able to customize your application and
environment as needed
the cool thing about this is that your
customizations are automated and because
you make them in these yaml
formatted.config files
they're version controlled alongside
your application for more information on
customizing your app with config files
head over to the elastic beanstalk
documentation where you'll find detailed
docs
specific to all of the languages and
platforms elastic bean stock supports
including java.net ruby php node.js and
python
and finally thanks for watching stay
tuned to the aws channel here on youtube
and visit the aws application management
blog for developer focused blog posts
about elastic beanstalk