Jason Mimick



<div class="introduction">

It's pretty amazing that we can now deploy and control massive systems
in the cloud from our laptops and phones. And it's so easy to take for
granted when it all works, but not so awesome when everything is broken
after coming back on Monday morning after a long weekend! On top of
that, the tooling that's available is constantly changing and updating
and soon you are drowning in dependabot PRs.

The reality of setting up and configuring all the tools necessary to
deploy an app is time-consuming, error-prone, and can result in security
risks if you're not careful. These are just a few of the reasons we've
all witnessed the incredible growth of DevOps tooling as we continue the
evolution to and in the cloud.

[AWS CloudFormation](https://aws.amazon.com/cloudformation/) is an
infrastructure-as-code (IaC) service that helps you model and set up
your Amazon Web Services resources so that you can spend less time
managing those resources and more time focusing on your applications
that run in AWS. CloudFormation, or CFN, let's users create and manage
AWS resources directly from templates which provide dependable out of
the box blueprint deployments for any kind of cloud app.

To better serve customers using modern cloud-native workflows, MongoDB
Atlas supports native CFN templates with a new set of Resource Types.
This new integration allows you to manage complete MongoDB Atlas
deployments through the AWS CloudFormation console and CLI so your apps
can securely consume data services with full AWS cloud ecosystem
support.

</div>

<div class="content">

## Launch a MongoDB Atlas Stack on AWS CloudFormation

We created a helper project that walks you through an end-to-end example
of setting up and launching a MongoDB Atlas stack in AWS CloudFormation.

The
[get-started-aws-cfn](https://github.com/mongodb-developer/get-started-aws-cfn)
project builds out a complete MongoDB Atlas deployment, which includes a
MongoDB Atlas project, cluster, AWS IAM role-type database user, and IP
access list entry.

>
>
>You can also use the [AWS Quick Start for MongoDB
>Atlas](https://aws.amazon.com/quickstart/architecture/mongodb-atlas/)
>that uses the same resources for CloudFormation and includes network
>peering to a new or existing VPC.
>
>

<img src="https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/old_images/aws-cloudformation/get-started-aws-cfn-demo.gif" class="align-center" alt="Deploy MongoDB Atlas using AWS CloudFormation" />

You're most likely already set up to run the
[get-started-aws-cfn](https://github.com/mongodb-developer/get-started-aws-cfn)
since the project uses common tools like the AWS CLI and Docker, but
just in case, head over to the
[prerequisites](https://github.com/mongodb-developer/get-started-aws-cfn#pre-requisites)
section to check your development machine. (If you haven't already,
you'll want to [create a MongoDB Atlas
account](https://www.mongodb.com/cloud/atlas/register).)

The project has two main parts: "get-setup' will deploy and configure
the MongoDB Atlas CloudFormation resources into the AWS region of your
choice, while "get-started' will launch your complete Atlas deployment.

## Step 1) Get Set Up

Clone the
[get-started-aws-cfn](https://github.com/mongodb-developer/get-started-aws-cfn)
repo and [get
setup](https://github.com/mongodb-developer/get-started-aws-cfn#get-setupsh):

``` bash
git clone https://github.com/mongodb-developer/get-started-aws-cfn
cd get-started-aws-cfn
./get-setup.sh
```

## Step 2) Get Started

Run the get-started script:

``` bash
./get-started.sh
```

<img src="https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/old_images/aws-cloudformation/get-started-aws-cfn-pic-1.png" class="align-center" alt="Launch a MongoDB Atlas deployment with the AWS CLI using CloudFormation with the Get Started project" />

Once the stack is launched, you will start to see resources getting
created in the AWS CloudFormation console. The Atlas cluster takes a few
minutes to spin up completely, and you can track the progress in the
console or through the AWS CLI.

<img src="https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/old_images/aws-cloudformation/get-started-aws-cfn-pic-2.png" class="align-center" alt="View and manage MongoDB Atlas resources from the AWS CloudFormation console." />

## Step 3) Get Connected

Once your MongoDB Atlas cluster is deployed successfully, you can find
its connection string under the Outputs tab as the value for the
"ClusterSrvAddress' key.

<img src="https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/old_images/aws-cloudformation/get-started-aws-cfn-pic-3.png" class="align-center" alt="Use the ClusterSrvAddress output in AWS CloudFormation to connect to your MongoDB Atlas cluster." />

The Get-Started project also has a helper script to combine the AWS and
MongoDB shells to securely connect via an AWS IAM role session. Check
out [connecting to your
cluster](https://github.com/mongodb-developer/get-started-aws-cfn#connecting-to-your-cluster)
for more information.

What next? You can connect to your MongoDB Atlas cluster from [the mongo
shell](https://docs.atlas.mongodb.com/mongo-shell-connection/), [MongoDB
Compass](https://docs.atlas.mongodb.com/compass-connection/), or any of
our supported
[drivers](https://docs.atlas.mongodb.com/driver-connection/). We have
guides for those using Atlas with popular languages: Here's one for [how
to connect to Atlas with
Node.js](https://developer.mongodb.com/quickstart/node-connect-mongodb-3-3-2/)
and another for [getting started with
Java](https://developer.mongodb.com/quickstart/java-setup-crud-operations/).

</div>

<div class="summary">

## Conclusion

Use the MongoDB Atlas CloudFormation Resources to power everything from
the most basic "hello-world' apps to the most advanced devops pipelines.
Jump start your new projects today with the [MongoDB Atlas AWS
CloudFormation Get-Started
project](https://github.com/mongodb-developer/get-started-aws-cfn)!

>
>
>If you have questions, please head to our [developer community
>website](https://community.mongodb.com/) where the MongoDB engineers and
>the MongoDB community will help you build your next big idea with
>MongoDB.
>
>

</div>


Learn how to get started with MongoDB Atlas and AWS CloudFormation.

Get Started with MongoDB Atlas and AWS CloudFormation

Nic Raboy

There are many methods available for interacting with MongoDB and depending on what you're trying to accomplish, one way to work with MongoDB might be better than another. For example, if you're a power user of Visual Studio Code, then the [MongoDB Extension for Visual Studio Code](https://code.visualstudio.com/docs/azure/mongodb) might make sense. If you're constantly working with infrastructure and deployments, maybe the [MongoDB CLI](https://docs.mongodb.com/mongocli/stable/) makes the most sense. If you're working with data but prefer a command line experience, the MongoDB Shell is something you'll be interested in.

The [MongoDB Shell](https://www.mongodb.com/products/shell) gives you a rich experience to work with your data through syntax highlighting, intelligent autocomplete, clear error messages, and the ability to extend and customize it however you'd like.

In this article, we're going to look a little deeper at the things we can do with the MongoDB Shell.

## Syntax Highlighting and Intelligent Autocomplete

If you're like me, looking at a wall of code or text that is a single color can be mind-numbing to you. It makes it difficult to spot things and creates overall strain, which could damage productivity. Most development IDEs don't have this problem because they have proper syntax highlighting, but it's common for command line tools to not have this luxury. However, this is no longer true when it comes to the MongoDB Shell because it is a command line tool that has syntax highlighting.

![MongoDB Shell Syntax Highlighting](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/mongosh_syntax_highlight_3c9ebac7b9.png "MongoDB Shell Syntax Highlighting")

When you write commands and view results, you'll see colors that match your command line setup as well as pretty-print formatting that is readable and easy to process.

Formatting and colors are only part of the battle that typical command line advocates encounter. The other common pain-point, that the MongoDB Shell fixes, is around autocomplete. Most IDEs have autocomplete functionality to save you from having to memorize every little thing, but it is less common in command line tools.

As you're using the MongoDB Shell, simply pressing the "Tab" key on your keyboard will bring up valuable suggestions related to what you're trying to accomplish.

![Autocomplete with the MongoDB Shell](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/mongosh_autocomplete_7a1ac066ae.gif "Autocomplete with the MongoDB Shell")

Syntax highlighting, formatting, and autocomplete are just a few small things that can go a long way towards making the developer experience significantly more pleasant.

## Error Messages that Actually Make Sense

How many times have you used a CLI, gotten some errors you didn't understand, and then either wasted half your day finding a missing comma or rage quit? It's happened to me too many times because of poor error reporting in whatever tool I was using.

With the MongoDB Shell, you'll get significantly better error reporting than a typical command line tool.

![MongoDB Shell Error Reporting](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/mongosh_error_reporting_4455bb3eca.png "MongoDB Shell Error Reporting")

In the above example, I've forgotten a comma, something I do regularly along with colons and semi-colons, and it told me, along with providing a general area on where the comma should go. That's a lot better than something like "Generic Runtime Error 0x234223."

## Extending the MongoDB Shell with Plugins Known as Snippets

If you use the MongoDB Shell enough, you'll probably reach a point in time where you wish it did something specific to your needs on a repetitive basis. Should this happen, you can always extend the tool with snippets, which are similar to plugins.

To get an idea of some of the official MongoDB Shell snippets, execute the following from the MongoDB Shell:

```bash
snippet search
```

The above command searches the snippets found in a repository on [GitHub](https://github.com/mongodb-labs/mongosh-snippets).

You can always define your own repository of snippets, but if you wanted to use one of the available but optional snippets, you could run something like this:

```bash
snippet install analyze-schema
```

The above snippet allows you to analyze any collection that you specify. So in the example of my "recipes" collection, I could do the following:

```bash
use food;
schema(db.recipes);
```

The results of the schema analysis, at least for my collection, is the following:

```
┌─────────┬───────────────┬───────────┬────────────┐
│ (index) │       0       │     1     │     2      │
├─────────┼───────────────┼───────────┼────────────┤
│    0    │ '_id        ' │ '100.0 %' │ 'ObjectID' │
│    1    │ 'ingredients' │ '100.0 %' │  'Array'   │
│    2    │ 'name       ' │ '100.0 %' │  'String'  │
└─────────┴───────────────┴───────────┴────────────┘
```

Snippets aren't the only way to extend functionality within the MongoDB Shell. You can also use Node.js in all its glory directly within the MongoDB Shell using custom scripts.

## Using Node.js Scripts within the MongoDB Shell

So let's say you've got a data need that you can't easily accomplish with the [MongoDB Query API](https://www.mongodb.com/mongodb-query-api) or an aggregation pipeline. If you can accomplish what you need using Node.js, you can accomplish what you need in the MongoDB Shell.

Let's take this example.

Say you need to consume some data from a remote service and store it in MongoDB. Typically, you'd probably write an application, download the data, maybe store it in a file, and load it into MongoDB or load it with one of the programming drivers. You can skip a few steps and make your life a little easier.

Try this.

When you are connected to the MongoDB Shell, execute the following commands:

```bash
use pokemon
.editor
```

The first will switch to a database—in this case, "pokemon"—and the second will open the editor. From the editor, paste in the following code:

```javascript
async function getData(url) {
    const fetch = require("node-fetch");
    const results = await fetch(url)
        .then(response => response.json());
    db.creatures.insertOne(results);
}
```

The above function will make use of the [node-fetch](https://www.npmjs.com/package/node-fetch) package from NPM. Then, using the package, we can make a request to a provided URL and store the results in a "creatures" collection.

You can execute this function simply by doing something like the following:

```bash
getData("https://pokeapi.co/api/v2/pokemon/pikachu");
```

If it ran successfully, your collection should have new data in it.

In regards to the NPM packages, you can either install them globally or to your current working directory. The MongoDB Shell will pick them up when you need them.

If you'd like to use your own preferred editor rather than the one that the MongoDB Shell provides you, execute the following command prior to attempting to open an editor:

```bash
config.set("editor", "vi");
```

The above command will make VI the default editor to use from within the MongoDB Shell. More information on using an external editor can be found in the [documentation](https://docs.mongodb.com/mongodb-shell/reference/editor-mode/#using-an-external-editor).

## Conclusion

You can do some neat things with the MongoDB Shell, and while it isn't for everyone, if you're a power user of the command line, it will certainly improve your productivity with MongoDB.

If you have questions, stop by the [MongoDB Community Forums](https://community.mongodb.com)!

Learn about the benefits of using the new MongoDB Shell for interacting with databases, collections, and the data inside.

Designing, Developing, and Analyzing with the New MongoDB Shell

Ella Shurhavetsky

Nuno Costa



<div class="introduction">

## Introduction

Systems' security plays a fundamental role in today's modern
applications. It is very important to restrict non-authorized users'
access to root capabilities. With this blog post, we intend to document
how to avoid jeopardizing root system resources, but allow authorized,
non-root users, to perform administrative operations on `mongod`
processes such as starting or stopping the daemon.

The methodology is easily extensible to other administrative operations
such as preventing non-authorized users from modifying `mongod` audit
logs.

Use this procedure for Linux based systems to allow users with
restricted permissions to stop/start/restart `mongod` processes. These
users are set up under a non-root Linux group. Further, the Linux group
of these users is different from the Linux user group under which the
`mongod` process runs.

</div>

<div class="prerequisites">

## Considerations

>
>
>WARNING: The procedure requires root access for the setup. Incorrect
>settings can lead to an unresponsive system, so always test on a
>development environment before implementing in production. Ensure you
>have a current backup of your data.
>
>

It's recommended to perform this procedure while setting up a new
system. If it is not possible, perform the procedure during the
maintenance window.

The settings will impact only one local system, thus in case of replica
set or a sharded cluster perform the procedure in a rolling matter and
never change all nodes at once.

## Tested Linux flavors

-   CentOS 6\|7
-   RHEL 6\|7
-   Ubuntu 18.04
-   Amazon Linux 2

>
>
>Disclaimer: For other Linux distributions the procedure should work in a
>similar way however, only the above versions were tested while writing
>this article.
>
>

</div>

<div class="content">

## Procedure

-   Add the user with limited permissions (replace testuser with your
    user):

``` bash
$ adduser testuser
$ groupadd testgroup
```

-   Install [MongoDB
    Community](https://docs.mongodb.com/manual/administration/install-on-linux/)
    \|
    [Enterprise](https://docs.mongodb.com/manual/administration/install-enterprise/)
    following our recommended procedures.
-   Edit the MongoDB configuration file `/etc/mongod.conf` permissions:

``` none
$ sudo chown mongod:mongod /etc/mongod.conf
$ sudo chmod 600 /etc/mongod.conf
$ ls -l /etc/mongod.conf
-rw-------. 1 mongod mongod 330 Feb 27 18:43 /etc/mongod.conf
```

With this configuration, only the mongod user (and root) will have
permissions to access and edit the `mongod.conf` file. No other user
will be allowed to read/write and have access to its content.

### Systems running with systemd

This procedure works for CentOS 7 and RHEL 7.

-   Add the following configuration lines to the
    [sudoers](https://www.sudo.ws/man/1.8.17/sudoers.man.html) file with
    [visudo](https://www.sudo.ws/man/1.8.13/visudo.man.html):

``` bash
%mongod ALL =(ALL) NOPASSWD: /bin/systemctl start mongod.service, /bin/systemctl stop mongod.service, /bin/systemctl restart mongod.service
%testuser ALL =(ALL) NOPASSWD: /bin/systemctl start mongod.service, /bin/systemctl stop mongod.service, /bin/systemctl restart mongod.service
```

>
>
>Note: The root user account may become non-functional if a syntax error
>is introduced in the sudoers file.
>
>

### Systems running with System V Init

This procedure works for CentOS 6, RHEL 6, Amazon Linux 2 and Ubuntu
18.04.

-   MongoDB init.d-mongod script is available on our repository
    [here](https://github.com/mongodb/mongo/blob/master/rpm/init.d-mongod)
    in case manual download is required (make sure you save it in the
    /etc/init.d/ directory with permissions set to 755).
-   Add the following configuration lines to the
    [sudoers](https://www.sudo.ws/man/1.8.17/sudoers.man.html) file with
    [visudo](https://www.sudo.ws/man/1.8.13/visudo.man.html):

For CentOS 6, RHEL 6 and Amazon Linux 2:

``` bash
%mongod ALL =(ALL) NOPASSWD: /sbin/service mongod start, /sbin/service mongod stop, /sbin/service mongod restart
%testuser ALL =(ALL) NOPASSWD: /sbin/service mongod start, /sbin/service mongod stop, /sbin/service mongod restart
```

For Ubuntu 18.04:

``` bash
%mongod ALL =(ALL) NOPASSWD: /usr/sbin/service mongod start, /usr/sbin/service mongod stop, /usr/sbin/service mongod restart
%testuser ALL =(ALL) NOPASSWD: /usr/sbin/service mongod start, /usr/sbin/service mongod stop, /usr/sbin/service mongod restart
```

>
>
>Note: The root may become non-functional if a syntax error is introduced
>in the sudoers file.
>
>

## Testing procedure

### Systems running with systemd (systemctl service)

So with these settings testuser has no permissions to read
/etc/mongod.conf but can start and stop the mongod service:

``` none
[testuser@localhost ~]$ sudo /bin/systemctl start mongod.service
[testuser@localhost ~]$ sudo /bin/systemctl stop mongod.service
[testuser@localhost ~]$ vi /etc/mongod.conf
"/etc/mongod.conf" [Permission Denied]
[testuser@localhost ~]$ sudo vi /etc/mongod.conf
"/etc/mongod.conf" [Permission Denied]
```

>
>
>Note: The authorization is given when using the `/bin/systemctl`
>command. With this procedure, the `sudo systemctl start mongod` will
>prompt the sudo password for the testuser.
>
>

### Systems running with System V Init

Use sudo service mongod \[start|stop|restart\]:

``` none
[testuser@localhost ~]$ sudo service mongod start
Starting mongod:                                           [  OK  ]
[testuser@localhost ~]$ sudo service mongod stop
Stopping mongod:                                           [  OK  ]
[testuser@localhost ~]$ vi /etc/mongod.conf
"/etc/mongod.conf" [Permission Denied]
[testuser@localhost ~]$ sudo vi /etc/mongod.conf
[sudo] password for testuser:
Sorry, user testuser is not allowed to execute '/bin/vi /etc/mongod.conf' as root on localhost.
```

>
>
>Note: Additionally, test restarting other services with the testuser
>with (and without) the required permissions.
>
>

</div>

<div class="summary">

## Wrap Up

It is one of the critical security requirements, not to give
unauthorized users full root privileges. With that requirement in mind,
it is important for system administrators to know that it is possible to
give access to actions like restart/stop/start for a `mongod` process
(or any other process) without giving root privileges, using Linux
systems capabilities.

>
>
>If you have questions, please head to our [developer community
>website](https://community.mongodb.com/) where the MongoDB engineers and
>the MongoDB community will help you build your next big idea with
>MongoDB.
>
>

</div>


Secure your MongoDB installation by allowing non-root users to stop/start/restart your mongod process.

Procedure to Allow Non-Root Users to Stop/Start/Restart "mongod" Process

Joel Lord

> This tutorial discusses the preview version of the Atlas Data API which is now generally available with more features and functionality. Learn more about the GA version [here](https://www.mongodb.com/developer/products/atlas/atlas-data-api-introduction/).

By now, you have most certainly heard about [Wordle](https://www.powerlanguage.co.uk/wordle/), the new word game that was created in October 2021 by a former Reddit engineer, [Josh Wardle](https://twitter.com/powerlanguish). It gained so much traction at the beginning of the year even Google has a secret easter egg for it when you search for the game.

I wanted to brush up on my Bash scripting skills, so I thought, “Why not create the Wordle game in Bash?” I figured this would be a good exercise that would include some `if` statements and loops. However, the word list I have available for the possible Wordles is in a MongoDB collection. Well, thanks to the new Atlas Data API, I can now connect to my MongoDB database directly from a Bash script.

Let’s get to work!

## Requirements
You can find the complete source code for this repository on [Github](https://github.com/mongodb-developer/bash-wordle). You can use any [MongoDB Atlas](https://www.mongodb.com/cloud/atlas/register) cluster for the data API part; a [free tier](https://docs.atlas.mongodb.com/tutorial/deploy-free-tier-cluster/) would work perfectly. 

You will need [Bash](https://www.gnu.org/software/bash/) Version 3 or more to run the Bash script. 

```bash
$ bash --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin20)
```

You will need [curl](https://curl.se/) to access the Data API. 

```bash
$ curl --version
curl 7.64.1 (x86_64-apple-darwin20.0) libcurl/7.64.1 (SecureTransport) LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.41.0
```

Finally, you will use [jq](https://stedolan.github.io/jq/) to manipulate JSON objects directly in the command line. 

```bash
jq --version
jq-1.6
```

## Writing the game

The game will run inside a while loop that will accept user inputs. The loop will go on until either the user finds the right word or has reached five tries without finding the right word. 

First, we’ll start by creating a variable that will hold the word that needs to be guessed by the user. In Bash, you don’t need to initialize variables; you can simply assign a value to it. To access the variable, you use the dollar sign followed by the variable's name.

```bash
WORD=MONGO
echo Hello $WORD
# Hello MONGO
```

Next up, we will need a game loop. In Bash, a `while` loop uses the following syntax.

```bash
while [ <condition> ]
do
  # Stuff
done
```

Finally, we will also need an if statement to compare the word. The syntax for `if` in Bash is as follows.

```bash
if [ <condition> ]
then
  # Stuff
elif [ <condition> ]
then
  # Optional else-if block
else 
  # Else block
fi
```


To get started with the game, we will create a variable for the while condition, ask the user for input with the `read` command, and exit if the user input matches the word we have hard-coded.

```bash
WORD=MONGO
GO_ON=1
while [ $GO_ON -eq 1 ]
do
  read -n 5 -p "What is your guess: " USER_GUESS
  if [ $USER_GUESS == $WORD ]
  then
    echo -e "You won!"
    GO_ON=0
  fi
done
```

Save this code in a file called `wordle.sh`, set the execute permission on the file, and then run it.

```bash
$ chmod +x ./wordle.sh
$ ./wordle.sh
```

So far, so good; we now have a loop that users can only exit if they find the right word. Let’s now make sure that they can only have five guesses. To do so, we will use a variable called TRIES, which will be incremented using `expr` at every guess. If it reaches five, then we change the value of the GO_ON variable to stop the main loop.

```bash
GO_ON=1
TRIES=0
while [ $GO_ON -eq 1 ]
do
  TRIES=$(expr $TRIES + 1)
  read -n 5 -p "What is your guess: " USER_GUESS
  if [ $USER_GUESS == $WORD ]
  then
    echo -e "You won!"
    GO_ON=0
  elif [ $TRIES == 5 ]
  then
    echo -e "You failed.\nThe word was "$WORD
    GO_ON=0
  fi
done
```

Let’s now compare the value that we got from the user and compare it with the word. Because we want the coloured squares, we will need to compare the two words letter by letter.  We will use a for loop and use the index `i` of the character we want to compare. For loops in Bash have the following syntax.

```bash
for i in {0…10}
do
  # stuff
done
```

We will start with an empty `STATE` variable for our round result. We will add a green square for each letter if it’s a match, a yellow square if the letter exists elsewhere, or a black square if it’s not part of the solution. Add the following block after the `read` line and before the `if` statement.

```bash
  STATE=""
  for i in {0..4}
  do
    if [ "${WORD:i:1}" == "${USER_GUESS:i:1}" ]
    then
      STATE=$STATE"🟩"
    elif [[ $WORD =~ "${USER_GUESS:i:1}" ]]
    then
      STATE=$STATE"🟨"
    else
      STATE=$STATE"⬛️"
    fi
  done
  echo "  "$STATE
```

Note how we then output the five squares using the `echo` command. This output will tell the user how close they are to finding the solution.

We have a largely working game already, and you can run it to see it in action. The only major problem left now is that the comparison is case-sensitive. To fix this issue, we can transform the user input into uppercase before starting the comparison. We can achieve this with a tool called `awk` that is frequently used to manipulate text in Bash. Right after the `read` line, and before we initialize the empty STATE variable, add the following line to uppercase the user input.

```bash
  USER_GUESS=$(echo "$USER_GUESS" | awk '{print toupper($0)}')
```

That’s it; we now have a fully working Wordle clone. 

## Connecting to MongoDB

We now have a fully working game, but it always uses the same start word. In order for our application to use a random word, we will start by populating our database with a list of words, and then pick one randomly from that collection. 

When working with MongoDB Atlas, I usually use the native driver available for the programming language I’m using. Unfortunately, no native drivers exist for Bash. That does not mean we can’t access the data, though. We can use curl (or another command-line tool to transfer data) to access a MongoDB collection using the new Data API.

To enable the data API on your MongoDB Atlas cluster, you can follow the instructions from the [Getting Started with the Data API article](https://www.mongodb.com/blog/post/introducing-mongodb-atlas-data-api-now-available-preview).

Let’s start with adding a single word to our `words` collection, in the `wordle` database. Each document will have a single field named `word`, which will contain one of the possible Wordles. To add this document, we will use the `insertOne` endpoint of the Data API.

Create a file called `insert_words.sh`. In that file, create three variables that will hold the URL endpoint, the API key to access the data API, and the cluster name.

```bash
API_KEY="<Your API Key>"
URL="<URL Endpoint For the Data API>"
CLUSTER="<Name of your Cluster>"
```

Next, use a curl command to insert a single document. As part of the payload for this request, you will add your document, which, in this case, is a JSON object with the word “MONGO.” Add the following to the `insert_words.sh` file.

```bash
curl --location --request POST  $URL'/action/insertOne' \
  --header 'Content-Type: application/json' \
  --header 'Access-Control-Request-Headers: *' \
  --header 'api-key: '$API_KEY \
  --data-raw '{
    "collection":"words",
    "database":"wordle",
    "dataSource":"'$CLUSTER'",
    "document": { "word": "MONGO" }
}'
```

Running this file, you should see a result similar to

```
{"insertedId":"620275c014c4be86ede1e4e7"}
```

This tells you that the insert was successful, and that the new document has this `_id`.

You can add more words to the list, or you can import the official list of words to your MongoDB cluster. You can find that list in the `words.json` file in this project’s [repository](https://github.com/mongodb-developer/bash-wordle). You can change the `insert_words.sh` script to use the raw content from Github to import all the possible Wordles at once with the following curl command. This command will use the `insertMany` endpoint to insert the array of documents from Github.

```bash
curl --location --request POST  $URL'/action/insertMany' \
  --header 'Content-Type: application/json' \
  --header 'Access-Control-Request-Headers: *' \
  --header 'api-key: '$API_KEY \
  --data-raw '{
    "collection":"words",
    "database":"wordle",
    "dataSource":"'$CLUSTER'",
    "documents": '$(curl -s https://raw.githubusercontent.com/mongodb-developer/bash-wordle/main/words.json)'
}'
```

Now back to the `wordle.sh` file, add two variables that will hold the URL endpoint, the API key to access the data API, and cluster name at the top of the file.

```bash
API_KEY="<Your API Key>"
URL_ENDPOINT="<URL Endpoint For the Data API>"
CLUSTER="<Name of your Cluster>"
```

Next, we’ll use a curl command to run an aggregation pipeline on our Wordle database. This aggregation pipeline will use the `$sample` stage to return one random word. The curl result will then be piped into `jq`, a tool to extract JSON data from the command line. Jq will return the actual value for the `word` field in the document we get from the aggregation pipeline. All of this is then assigned to the WORD variable. 

Right after the two new variables, you can add this code.

```bash
WORD=$(curl --location --request POST -s $URL'/action/aggregate' \
--header 'Content-Type: application/json' \
--header 'Access-Control-Request-Headers: *' \
--header 'api-key: '$API_KEY \
--data-raw '{
    "collection":"words",
    "database":"wordle",
    "dataSource":"Cluster0",
    "pipeline": [{"$sample": {"size": 1}}]
}' | jq -r .documents[0].word)

```

And that’s it! Now, each time you run the `wordle.sh` file, you will get to try out a new word.

```
What is your guess: mongo  ⬛️🟨🟨⬛️🟨
What is your guess: often  🟨⬛️⬛️⬛️🟩
What is your guess: adorn  🟨⬛️🟨🟨🟩
What is your guess: baron  ⬛️🟩🟨🟩🟩
What is your guess: rayon  🟩🟩🟩🟩🟩
You won!
```

## Summary

That’s it! You now have your very own version of Wordle so that you can practice over and over directly in your favorite terminal. This version only misses one feature if you’re up to a challenge. At the moment, any five letters are accepted as input. Why don’t you add a validation step so that any word input by the user must have a match in the collection of valid words? You could do this with the help of the data API again. Don’t forget to submit a pull request to the repository if you manage to do it!







Learn how to build a Wordle clone using bash and the MongoDB Data API.

Build Your Own Wordle in Bash with the Data API

Need a consistent development and deployment experience as developers work across teams and use different machines for their daily tasks? That is where Docker has you covered with containers. A common experience might include running a local version of MongoDB Community in a container and an application in another container. This strategy works for some organizations, but what if you want to leverage all the benefits that come with MongoDB Atlas in addition to a container strategy for your application development?

In this tutorial we'll see how to create a MongoDB-compatible web application, bundle it into a container with Docker, and manage creation as well as destruction for MongoDB Atlas with the [Atlas CLI](https://www.mongodb.com/docs/atlas/cli/stable/) during container deployment.

It should be noted that this tutorial was intended for a development or staging setting through your local computer. It is not advised to use all the techniques found in this tutorial in a production setting. Use your best judgment when it comes to the code included.

If you’d like to try the results of this tutorial, check out the repository and instructions on [GitHub](https://github.com/mongodb-developer/atlas-cli-docker-example).

## The prerequisites

There are a lot of moving parts in this tutorial, so you'll need a few things prior to be successful:

- A [MongoDB Atlas](https://www.mongodb.com/atlas/database) account
- [Docker](https://www.docker.com/)
- Some familiarity with Node.js and JavaScript

The [Atlas CLI](https://www.mongodb.com/docs/atlas/cli/stable/) can create an Atlas account for you along with any keys and ids, but for the scope of this tutorial you'll need one created along with quick access to the "Public API Key", "Private API Key", "Organization ID", and "Project ID" within your account. You can see how to do this in the [documentation](https://www.mongodb.com/docs/atlas/configure-api-access/#grant-programmatic-access-to-service).

Docker is going to be the true star of this tutorial. You don't need anything beyond [Docker](https://www.docker.com/) because the Node.js application and the Atlas CLI will be managed by the Docker container, not your host computer.

On your host computer, create a project directory. The name isn't important, but for this tutorial we'll use **mongodbexample** as the project directory.

## Create a simple Node.js application with Express Framework and MongoDB

We're going to start by creating a Node.js application that communicates with MongoDB using the [Node.js driver for MongoDB](https://www.mongodb.com/docs/drivers/node/current/). The application will be simple in terms of functionality. It will connect to MongoDB, create a database and collection, insert a document, and expose an API endpoint to show the document with an HTTP request.

Within the project directory, create a new **app** directory for the Node.js application to live. Within the **app** directory, using a command line, execute the following:

```bash
npm init -y
npm install express mongodb
```

If you don't have Node.js installed, just create a **package.json** file within the **app** directory with the following contents:

```json
{
    "name": "mongodbexample",
    "version": "1.0.0",
    "description": "",
    "main": "main.js",
    "scripts": {
        "test": "echo \"Error: no test specified\" && exit 1",
        "start": "node main.js"
    },
    "keywords": [],
    "author": "",
    "license": "ISC",
    "dependencies": {
        "express": "^4.18.2",
        "mongodb": "^4.12.1"
    }
}
```

Next, we'll need to define our application logic. Within the **app** directory we need to create a **main.js** file. Within the **main.js** file, add the following JavaScript code:

```javascript
const { MongoClient } = require("mongodb");
const Express = require("express");

const app = Express();

const mongoClient = new MongoClient(process.env.MONGODB_ATLAS_URI);
let database, collection;

app.get("/data", async (request, response) => {
    try {
        const results = await collection.find({}).limit(5).toArray();
        response.send(results);
    } catch (error) {
        response.status(500).send({ "message": error.message });
    }
});

const server = app.listen(3000, async () => {
    try {
        await mongoClient.connect();
        database = mongoClient.db(process.env.MONGODB_DATABASE);
        collection = database.collection(`${process.env.MONGODB_COLLECTION}`);
        collection.insertOne({ "firstname": "Nic", "lastname": "Raboy" });
        console.log("Listening at :3000");
    } catch (error) {
        console.error(error);
    }
});

process.on("SIGTERM", async () => {
    if(process.env.CLEANUP_ONDESTROY == "true") {
        await database.dropDatabase();
    }
    mongoClient.close();
    server.close(() => {
        console.log("NODE APPLICATION TERMINATED!");
    });
});
```

There's a lot happening in the few lines of code above. We're going to break it down!

Before we break down the pieces, take note of the environment variables used throughout the JavaScript code. We'll be passing these values through Docker in the end so we have a more dynamic experience with our local development.

The first important snippet of code to focus on is the start of our application service:

```javascript
const server = app.listen(3000, async () => {
    try {
        await mongoClient.connect();
        database = mongoClient.db(process.env.MONGODB_DATABASE);
        collection = database.collection(`${process.env.MONGODB_COLLECTION}`);
        collection.insertOne({ "firstname": "Nic", "lastname": "Raboy" });
        console.log("Listening at :3000");
    } catch (error) {
        console.error(error);
    }
});
```

Using the client that was configured near the top of the file, we can connect to MongoDB. Once connected, we can get a reference to a database and collection. This database and collection doesn't need to exist before that because it will be created automatically when data is inserted. With the reference to a collection, we insert a document and begin listening for API requests through HTTP.

This brings us to our one and only endpoint:

```javascript
app.get("/data", async (request, response) => {
    try {
        const results = await collection.find({}).limit(5).toArray();
        response.send(results);
    } catch (error) {
        response.status(500).send({ "message": error.message });
    }
});
```

When the `/data` endpoint is consumed, the first five documents in our collection are returned to the user. Otherwise if there was some issue, an error message would be returned.

This brings us to something optional, but potentially valuable when it comes to a Docker deployment for local development:

```javascript
process.on("SIGTERM", async () => {
    if(process.env.CLEANUP_ONDESTROY == "true") {
        await database.dropDatabase();
    }
    mongoClient.close();
    server.close(() => {
        console.log("NODE APPLICATION TERMINATED!");
    });
});
```

The above code says that when a termination event is sent to the application, drop the database we had created and close the connection to MongoDB as well as the Express Framework service. This could be useful if we want to undo everything we had created when the container stops. If you want your changes to persist, it might not be necessary. For example, if you want your data to exist between container deployments, persistence would be required. On the other hand, maybe you are using the container as part of a test pipeline and you want to clean up when you’re done, the termination commands could be valuable.

So we have an environment variable heavy Node.js application. What's next?

## Deploying a MongoDB Atlas cluster with network rules, user roles, and sample data

While we have the application, our MongoDB Atlas cluster may not be available to us. For example, maybe this is our first time being exposed to Atlas and nothing has been created yet. We need to be able to quickly and easily create a cluster, configure our IP access rules, specify users and permissions, and then connect with our Node.js application.

This is where the MongoDB Atlas CLI does the heavy lifting!

There are many different ways to create a script. Some like Bash, some like ZSH, some like something else. We're going to be using ZX which is a JavaScript wrapper for Bash.

Within your project directory, not your **app** directory, create a **docker_run_script.mjs** file with the following code:

```javascript
#!/usr/bin/env zx

$.verbose = true;

const runtimeTimestamp = Date.now();

process.env.MONGODB_CLUSTER_NAME = process.env.MONGODB_CLUSTER_NAME || "examples";
process.env.MONGODB_USERNAME = process.env.MONGODB_USERNAME || "demo";
process.env.MONGODB_PASSWORD = process.env.MONGODB_PASSWORD || "password1234";
process.env.MONGODB_DATABASE = process.env.MONGODB_DATABASE || "business_" + runtimeTimestamp;
process.env.MONGODB_COLLECTION = process.env.MONGODB_COLLECTION || "people_" + runtimeTimestamp;
process.env.CLEANUP_ONDESTROY = process.env.CLEANUP_ONDESTROY || false;

var app;

process.on("SIGTERM", () => { 
    app.kill("SIGTERM");
});

try {
    let createClusterResult = await $`atlas clusters create ${process.env.MONGODB_CLUSTER_NAME} --tier M0 --provider AWS --region US_EAST_1 --output json`;
    await $`atlas clusters watch ${process.env.MONGODB_CLUSTER_NAME}`
    let loadSampleDataResult = await $`atlas clusters loadSampleData ${process.env.MONGODB_CLUSTER_NAME} --output json`;
} catch (error) {
    console.log(error.stdout);
}

try {
    let createAccessListResult = await $`atlas accessLists create --currentIp --output json`;
    let createDatabaseUserResult = await $`atlas dbusers create --role readWriteAnyDatabase,dbAdminAnyDatabase --username ${process.env.MONGODB_USERNAME} --password ${process.env.MONGODB_PASSWORD} --output json`;
    await $`sleep 10`
} catch (error) {
    console.log(error.stdout);
}

try {
    let connectionString = await $`atlas clusters connectionStrings describe ${process.env.MONGODB_CLUSTER_NAME} --output json`;
    let parsedConnectionString = new URL(JSON.parse(connectionString.stdout).standardSrv);
    parsedConnectionString.username = encodeURIComponent(process.env.MONGODB_USERNAME);
    parsedConnectionString.password = encodeURIComponent(process.env.MONGODB_PASSWORD);
    parsedConnectionString.search = "retryWrites=true&w=majority";
    process.env.MONGODB_ATLAS_URI = parsedConnectionString.toString();
    app = $`node main.js`;
} catch (error) {
    console.log(error.stdout);
}
```

Once again, we're going to break down what's happening!

Like with the Node.js application, the ZX script will be using a lot of environment variables. In the end, these variables will be passed with Docker, but you can hard-code them at any time if you want to test things outside of Docker.

The first important thing to note is the defaulting of environment variables:

```javascript
process.env.MONGODB_CLUSTER_NAME = process.env.MONGODB_CLUSTER_NAME || "examples";
process.env.MONGODB_USERNAME = process.env.MONGODB_USERNAME || "demo";
process.env.MONGODB_PASSWORD = process.env.MONGODB_PASSWORD || "password1234";
process.env.MONGODB_DATABASE = process.env.MONGODB_DATABASE || "business_" + runtimeTimestamp;
process.env.MONGODB_COLLECTION = process.env.MONGODB_COLLECTION || "people_" + runtimeTimestamp;
process.env.CLEANUP_ONDESTROY = process.env.CLEANUP_ONDESTROY || false;
```

The above snippet isn't a requirement, but if you want to avoid setting or passing around variables, defaulting them could be helpful. In the above example, the use of `runtimeTimestamp` will allow us to create a unique database and collection should we want to. This could be useful if numerous developers plan to use the same Docker images to deploy containers because then each developer would be in a sandboxed area. If the developer chooses to undo the deployment, only their unique database and collection would be dropped.

Next we have the following:

```javascript
process.on("SIGTERM", () => { 
    app.kill("SIGTERM");
});
```

We have something similar in the Node.js application as well. We have it in the script because eventually the script controls the application. So when we (or Docker) stops the script, the same stop event is passed to the application. If we didn't do this, the application would not have a graceful shutdown and the drop logic wouldn't be applied.

Now we have three try / catch blocks, each focusing on something particular.

The first block is responsible for creating a cluster with sample data:

```javascript
try {
    let createClusterResult = await $`atlas clusters create ${process.env.MONGODB_CLUSTER_NAME} --tier M0 --provider AWS --region US_EAST_1 --output json`;
    await $`atlas clusters watch ${process.env.MONGODB_CLUSTER_NAME}`
    let loadSampleDataResult = await $`atlas clusters loadSampleData ${process.env.MONGODB_CLUSTER_NAME} --output json`;
} catch (error) {
    console.log(error.stdout);
}
```

If the cluster already exists, an error will be caught. We have three blocks because in our scenario, it is alright if certain parts already exist.

Next we worry about users and access:

```javascript
try {
    let createAccessListResult = await $`atlas accessLists create --currentIp --output json`;
    let createDatabaseUserResult = await $`atlas dbusers create --role readWriteAnyDatabase,dbAdminAnyDatabase --username ${process.env.MONGODB_USERNAME} --password ${process.env.MONGODB_PASSWORD} --output json`;
    await $`sleep 10`
} catch (error) {
    console.log(error.stdout);
}
```

We want our local IP address to be added to the access list and we want a user to be created. In this example, we are creating a user with extensive access, but you may want to refine the level of permission they have in your own project. For example, maybe the container deployment is meant to be a sandboxed experience. In this scenario, it makes sense that the user created access only the database and collection in the sandbox. We `sleep` after these commands because they are not instant and we want to make sure everything is ready before we try to connect.

Finally we try to connect:

```javascript
try {
    let connectionString = await $`atlas clusters connectionStrings describe ${process.env.MONGODB_CLUSTER_NAME} --output json`;
    let parsedConnectionString = new URL(JSON.parse(connectionString.stdout).standardSrv);
    parsedConnectionString.username = encodeURIComponent(process.env.MONGODB_USERNAME);
    parsedConnectionString.password = encodeURIComponent(process.env.MONGODB_PASSWORD);
    parsedConnectionString.search = "retryWrites=true&w=majority";
    process.env.MONGODB_ATLAS_URI = parsedConnectionString.toString();
    app = $`node main.js`;
} catch (error) {
    console.log(error.stdout);
}
```

After the first try / catch block finishes, we'll have a connection string. We can finalize our connection string with a Node.js URL object by including the username and password, then we can run our Node.js application. Remember, the environment variables and any manipulations we made to them in our script will be passed into the Node.js application.

## Transition the MongoDB Atlas workflow to containers with Docker and Docker Compose

At this point, we have an application and we have a script for preparing MongoDB Atlas and launching the application. It's time to get everything into a Docker image to be deployed as a container.

At the root of your project directory, add a **Dockerfile** file with the following:

```dockerfile
FROM node:18

WORKDIR /usr/src/app

COPY ./app/* ./
COPY ./docker_run_script.mjs ./

RUN curl https://fastdl.mongodb.org/mongocli/mongodb-atlas-cli_1.3.0_linux_x86_64.tar.gz --output mongodb-atlas-cli_1.3.0_linux_x86_64.tar.gz
RUN tar -xvf mongodb-atlas-cli_1.3.0_linux_x86_64.tar.gz && mv mongodb-atlas-cli_1.3.0_linux_x86_64 atlas_cli
RUN chmod +x atlas_cli/bin/atlas
RUN mv atlas_cli/bin/atlas /usr/bin/

RUN npm install -g zx
RUN npm install

EXPOSE 3000

CMD ["./docker_run_script.mjs"]
```

The custom Docker image will be based on a Node.js image which will allow us to run our Node.js application as well as our ZX script.

After our files are copied into the image, we run a few commands to download and extract the MongoDB Atlas CLI.

Finally, we install ZX and our application dependencies and run the ZX script. The `CMD` command for running the script is done when the container is run. Everything else is done when the image is built.

We could build our image from this **Dockerfile** file, but it is a lot easier to manage when there is a Compose configuration. Within the project directory, create a **docker-compose.yml** file with the following YAML:

```yaml
version: "3.9"
services:
    web:
        build:
            context: .
            dockerfile: Dockerfile
        ports:
            - "3000:3000"
        environment:
            MONGODB_ATLAS_PUBLIC_API_KEY: YOUR_PUBLIC_KEY_HERE
            MONGODB_ATLAS_PRIVATE_API_KEY: YOUR_PRIVATE_KEY_HERE
            MONGODB_ATLAS_ORG_ID: YOUR_ORG_ID_HERE
            MONGODB_ATLAS_PROJECT_ID: YOUR_PROJECT_ID_HERE
            MONGODB_CLUSTER_NAME: examples
            MONGODB_USERNAME: demo
            MONGODB_PASSWORD: password1234
            # MONGODB_DATABASE: sample_mflix
            # MONGODB_COLLECTION: movies
            CLEANUP_ONDESTROY: true
```

You'll want to swap the environment variable values with your own. In the above example, the database and collection variables are commented out so the defaults would be used in the ZX script.

To see everything in action, execute the following from the command line on the host computer:

```bash
docker-compose up
```

The above command will use the **docker-compose.yml** file to build the Docker image if it doesn't already exist. The build process will bundle our files, install our dependencies, and obtain the MongoDB Atlas CLI. When Compose deploys a container from the image, the environment variables will be passed to the ZX script responsible for configuring MongoDB Atlas. When ready, the ZX script will run the Node.js application, further passing the environment variables. If the `CLEANUP_ONDESTROY` variable was set to `true`, when the container is stopped the database and collection will be removed.

## Conclusion

The [MongoDB Atlas CLI](https://www.mongodb.com/docs/atlas/cli/stable/) can be a powerful tool for bringing MongoDB Atlas to your local development experience on Docker. Essentially you would be swapping out a local version of MongoDB with Atlas CLI logic to manage a more feature-rich cloud version of MongoDB.

MongoDB Atlas enhances the MongoDB experience by giving you access to more features such as Atlas Search, Charts, and App Services, which allow you to build great applications with minimal effort.

Learn how to use the MongoDB Atlas CLI with Docker in this example that includes JavaScript and Node.js.

Bash

All Bash Content

Local Development with the MongoDB Atlas CLI and Docker

Build Your Own Wordle in Bash with the Data API

Procedure to Allow Non-Root Users to Stop/Start/Restart "mongod" Process

Get Started with MongoDB Atlas and AWS CloudFormation

Designing, Developing, and Analyzing with the New MongoDB Shell

Related Topics