So to show you how to work with that.
I will now switch to MongoDB Atlas
and use that instead of my own Mongo container.
And we can switch easily
because getting started with it is free.
You don't need to pay initially,
but of course, as always and as before with AWS,
you always want to check out the pricing pages
to learn more about pricing as you grow.
And as you want to work with that in production,
but getting started is possible for free.
We can simply click on start free,
fill in the details here and create our account.
Now, if you just created your account
you might see some getting started screen.
I already had an account
and either way you should find a button to create
or build a new cluster
because that's what we're going to do.
And the clusters here have nothing to do
with the AWS, ECS clusters.
It's just a similar term
because again, we can have a cluster
with multiple MongoDB databases inside of it.
So we are going to create a cluster here
and we are going to use the shared cluster
because that's available for free.
Now here, you still choose a cloud provider
because under the hood
MongoDB Atlas also uses a cloud provider
but you don't have to use AWS here
just because we used it before.
You don't need to log into these providers.
You don't even need an account with them.
MongoDB will work with them under the hood.
I will stick to AWS,
but you could choose any cloud provider.
You just want to make sure that ultimately
you end up with a combination,
which you can launch for free.
And I will go with AWS
stay with the default region here on the cluster tier.
I will use the M0 sandbox, which is free.
So which we can get started with for free.
On additional settings, I will leave the defaults here
and on cluster name I will also keep the default
though of course you can rename this
and then we can simply create this cluster.
And this will now take a short while
and it will set up all the cloud resources
under the hood behind the scenes.
And it will give us a cloud MongoDB database
to which we can connect.
Now, once the cluster was created and is up and running,
you can click on connect here
to learn how to connect to this cluster.
And we want to connect an application
because we got an application here.
We got our backend node rest API,
which is talking to MongoDB,
and that's the application we want to connect.
Currently, we're manually connecting
to our MongoDB container
but now we want to connect to this cloud MongoDB service.
Now the cool thing is,
here you see that connection string,
which you should use now.
And it's very similar to the string we used before
there we used MongoDB
then double slashes here, then our username our password
the URL or domain name, the port and then the database name
and this query parameter.
Now it's MongoDB plus SRV
at the beginning,
then still username and password
still a domain name in the end here
then the database name and then this query parameter
which is a different one than before
but overall, we can simply copy this connection string
and use that instead of the existing one.
And now we have a general decision to make.
Do we want to use MongoDB Atlas
in production only, or also during development?
Now you can find arguments for both approaches.
We could use a MongoDB container during development
and MongoDB Atlas during production
so that we don't hit our cloud MongoDB database
whilst we're working on the application
whilst we're testing it.
Though we could also solve that problem
by simply connecting to a different database here
in development than we do in production
so that we don't work with the production data
in development.
So we don't necessarily need a container in development
just to avoid working with the production data
in the database.
Using a different database
on one at the same MongoDB cluster or instance
would be a solution for that.
Nonetheless, we could argue
that we want to use a container during development
for this fully isolated development only environment
and then use the cloud database for production.
But that of course would mean
that we don't have exactly the same environment
during development and during production.
Because it is worth pointing out
that our MongoDB cluster here
uses a certain version of MongoDB.
In my case, 4.2.9.
This means that when we want to use a container
during development.
We have to ensure that we use the exact same version here.
So we must fetch the exact same version during development.
And we should avoid,
that we, for example use the Mongo container
based on Mongo 4.4,
in my specific case here
because then we would be using a later version of Mongo
during development.
Than we do in production.
And this might cause us to accidentally
use some NextGen MongoDB feature
which works fine during development
but won't work once we use this MongoDB cloud service
in production.
And that's defeats the idea behind using containers
that we have to same environment in development
as we have it in production.
So that is something we would have to watch out for.
We always would need to check our production MongoDB version
and ensure that we use the same version
for our development container.
If we do that though, it would be fine
and we could absolutely use a container during development
and the cloud database during production.
We then just would need to find a different way
of constructing this string to stay like this.
When we talk to a container
and to look like
this, when we talk to the production database
but with help of environment variables
that shouldn't be a great challenge.
So long story short, you can find arguments for both.
But I think it's better
if we really use the same
the exact same environment
in development and production
and therefore, I always want to use my cloud service here.
So that means that this will be my connection string
and I will there for now use that.
I will copy this query parameter here at the end
and replace my current query parameter
in the connection string with it,
I will copy this protocol here at the beginning
and use that instead of just Mongo DB.
And now we don't need a port anymore.
So we can remove that
because this is not part of the connection string
we see here.
I now want to make that database name flexible though
so that we can use a different database
for development and for production
so that we don't accidentally override production data.
When we are playing around
with our application in development.
So here we can introduce a new environment variable
and maybe name this MongoDB
database
or simply MongoDB name, whatever you want.
Now, this environment variable will also be registered
in the Docker file
and I'll set the default value here of goals-dev
so that my default database name is goals-dev.
And in production we could override this with just goals
to ensure that we use the right database name.
I will also already set it
in my backend.env file here.
There I will also add this
so that the default in my Docker file
is overwritten with this value,
which of course holds the same value
but simply to show you how you can use this env file.
So now we got this development set up
and our code is now flexible enough
to use the same cloud provider
the same cloud MongoDB database provider
during development and production.
Now, what does this mean
for our deployed containers now though?
And what does it mean for our docker-compose file?
Well, let's maybe start with docker-compose
and with our local setup.
Since we now have our database in the cloud
we no longer launch our own MongoDB container.
So that means,
we can get rid of this MongoDB service here entirely.
We don't need it anymore.
This also means of course,
that in backend.env for the MongoDB URL
we no longer use the MongoDB container name
but instead we'll use this URL here
which we find in this connection string.
So let's add this here,
so that this is the URL we're using.
When we try to connect to MongoDB.
It also means we can remove that volumes part here
in the docker-compose file because that data volume,
which was used by the MongoDB service
is not needed anymore.
And of course we could also delete this code
and we could also delete the Mongo.env file now
because we won't have a MongoDB container anymore.
We're not going to use it anymore
for the reasons I outlined over the last minutes
I will keep it here for reference though, but save it now.
And now we can give this a quick try.
We can simply run docker-compose up here
and see whether that works.
And I get an error because I have this depends on key here.
And of course, I'm trying to depend
on a container which doesn't exist anymore.
So let's remove this too.
And now we can try this again.
So now this builds our updated backend image
and then once it is done building that,
it should bring up that backend service
which then hopefully is still able to connect to MongoDB.
Now, however, with MongoDB in the cloud.
However, this fails
and it fails if we expand this
with an error
that in the end tells us that it could not connect
and it even tells us what the problem could be
because of course, MongoDB Atlas
also has certain security mechanisms.
We can control which IP addresses might connect here.
And we can, of course also add users
and use user credentials to control who's able to connect.
So therefore we of course want to use that
and configure our cluster to control who's able to connect.
And that starts with the network access.
Here I already got a bunch of IP addresses added.
You want to add an IP address here
and either add your current IP address only
or allow access from anywhere,
all due to radar.
So that later also my deployed application
on the AWS servers is able to connect
but you need to white list some IP address here.
So I will allow access from anywhere and confirm this.
But besides that under database access
you can add and configure users for this database.
Now I already got a couple of users here.
You should at least add one new user with a password
and give that user read and write access to the database.
Now, I already did that here for Max,
but I will add a new auto-generated password here.
Which I'll of course delete after this video recording.
So you don't have to try it .
I'll lock down this database in general
and copy that
and click update user.
This user is even an admin.
So therefore let me actually grab another user here
generate a password, grab that password.
This user has read and write access and update this user.
And now with that, we can go back to our backend.env file
and there, I want to use this new username
in my case Maximilian
and this generated password for connecting.
And now once all these changes have been deployed
on MongoDB Atlas once that is done.
We should be able to connect successfully.
So let's wait for these changes to have an effect there.
Quit this running docker-compose process
and restarted with docker-compose up
and now disconnected to MongoDB.
And therefore
if we quickly test this by accessing local host slash goals.
We get back this empty goals response.
Which proves that we're successfully querying the database.
Of course there is no data in it yet,
but that can change of course.
So that's how we can use MongoDB Atlas in development
and why we might want to consider using it.
Now, the main reason for switching to it
of course, was for production.
So how can we use it there.