Well, it's not that difficult.
In the end in AWS ECS,
we now just wanna get rid of that Mongo container
and make sure that we run the node back in container
such that we pass in the correct connection string
and credentials and database name
for our cloud MongoDB database.
For that, we can go to task definitions on AWS ECS
and go to our latest goals, task definition,
and create a new revision.
Now, here we can leave all this settings we had,
but of course we wanna get rid of the MongoDB container.
So simply delete it from that list.
We therefor can also get rid of that volume
and therefore we can, of course also get rid
of all the other volume-related resources.
So we can open EFS in a new tab,
this EFS service, and delete this EFS file system,
unless we also use it for something else,
but here, since I only used it for MongoDB,
I can delete this file system.
And of course you can then also go to the EC2 area
and delete the security group,
which we created just for this file system.
This one.
You don't have to do that,
but I like to keep my things cleaned up
so that I don't have resources lying around
which I don't need anymore.
So with that cleaned up,
back in the task definition page here,
we now wanna change the configuration
of goals-backend of this node, API container.
It generally stays the way it is,
but we now need to connect to MongoDB differently.
Our URL is no longer local host,
instead, this is now this cluster URL here.
So we should use stat here.
Now my username is this username
and my password now is this password.
So we should copy that over.
In addition, we have to new MongoDB name variable
for the database name, and that should be just goals here,
not goals-dev, because that's my development database,
but just goals here for production.
And with that, we should be fine.
Now we can click Update,
and then create this new task revision,
and then update our service to redeploy itself
or rerun this task.
Now we can also go back to the latest platform version
since we're not using an EFS volume anymore,
we can also click force new deployment
and skip to review and update this service.
And now this service will again replace a curly running task
with a brand new one based on these new settings
and once that is done,
which again, will take a couple of minutes,
we again will have our application up and running
again with no data for the moment,
but now connected to this cloud MongoDB service.
And that of course means that in the future,
we don't have to worry about this database at all.
It's fully managed for us,
the backups there are managed for us, and so on,
and we can manage and configure it
from inside this MongoDB Atlas screen,
which has nothing to do with AWS and containers,
but which can make a lot of sense to be used
instead of database containers,
since database containers bring their very own complexity.
So with that, let's wait for this new task revision,
this new task to be up and running,
and therefore our updated node API container
to be up and running, and let's then give it a try.
So now only my latest task is up and running
and I can now again, use PostMan to test it.
The load balancing URL hasn't changed,
so we should still be able to use that
and send a request to goals, and does seems to fail.
Now, actually, of course, I forgot one important thing.
It's nice that I updated my Docker file
within new a environment variable and my code,
but what did I forget for deploying this to the cloud?
Well, of course we need to rebuild our image
and push it to Docker hub again,
otherwise, we restart this task
still based on the old node image,
which still tries to connect to the MongoDB container
in the end,
or which didn't have the updated code
for connecting to Atlas at least.
It didn't use this new connection string and so on.
So of course that is a mistake from my side,
but it's also good to see that too.
Well, keep in mind that you always need to do that.
Repost your images if you changed your code,
and that's why I left it in here,
because, well, it is easy to overlook.
So we wanna rebuild our backend image and give it a tag,
ad now to save some time, I will immediately name it,
academind/goals-node,
which is my Docker hub repository name I've been using here,
and built this image under the name,
then log into Docker and then push academind/goals-node.
So that this updated image with the updated source code
is pushed to Docker hub,
and that is required to ensure
that its latest image is considered.
So now with debt back in my ECS goals app service,
we can go to that service,
click update and force a new deployment,
which will then pull the latest image.
So click Update Service here, view the service,
and now let's wait for this to finish.
Let's wait for this latest version to now start up so that
we now finally do have our container up and running again
with that latest image being used.
So now finally, that this is up and running,
we can try sending this request again,
and now this looks better and I can see my empty goals here.
Adding a goal should of course, all the work now,
so adding this first test goal, here it is.
And now of course we can also fetch this.
And since our database is now managed by a cloud provider
and running totally detached from our containers,
data will automatically persist because MongoDB Atlas
will take care about that.
And that's how we can move from a database container
to a cloud provider.
In this case, MongoDB Atlas,
and why we might wanna do this.
Again, if you are an expert on all of that,
if you're a cloud expert,
you can manage all of that on your own,
you don't have to make that switch,
but if you wanna build a big application
and you're not a database administration expert,
and you don't wanna deal with availability
and multiple database nodes and backups,
then using managed services like this
can be worth a thought.