Basic ReplicaSet Deployment of MongoDB

the deployment consists of three members in localhost, here considering the situation from converting a standalone mongod instance(mongodb enterprise edition 3.2), and enables access control.

simple deployment procedure

(1)a ready and standalone mongodb instance
(2)create separate data directory for three members
(3)(optional)create config file with specific startup option, resembling as an example

...net:    bindIp: 127.0.0.1replication:    replSetName: "dev_rs"security:    keyFile: "key file path"...

(4) start up mongod with -f option if using (3)
mongod --port port_num -f config_file --auth

(5)connect server instance by mongo client
mongo --port port_num

some notes:

• if enabling access control, need to make internal authentication when a certain member is in RECOVERING status.

access control

at the beginning, create first user as user administrator in db system in two ways below,

(1)start up mongod instance without access control
(2)with –auth CLI args, enabling during mongod startup
Under the circumstance, a localhost exception is provided

general instructions for both:

use admin#Note: the user with userAdmin or userAdminAnyDatabasedb.createUser(user_doc,writeConcern)

for example, in admin database, create the user called admin_user with built-in role called userAdminAnyDatabase.

use admin[admin|db].createUser({user:'admin_user',pwd:'***',roles:[{role:'userAdminAnyDatabase',db:'admin'}|'userAdminAnyDatabase']

after that operations, you can manipulate users and roles in any databases of current db system.

basic user management

(1)create a user
for example, create a user in db called testdev

use testdevdb.createUser({user:'test_user',pwd:'***',roles:[{role:'read',db:'admin'},'readWrite']})

at this time, the user test_user with specific built-in roles almost CRUD data.

basic role management

(1)create a user-defined role
As existing built-in roles may not implement desired set of privileges, you can also create some new ones.
Conventions:
(1.1)A role is uniquely determined by combination of database and role name
(1.2)Except for roles created in the admin database, a role can only include privileges that apply to its database and can only inherit from other roles in its database
(1.3)centralized Role data in system.roles collection in admin db.

for example,simply create a role called f_role for specific collection called testcol in testdev db

use testdevdb.createRole({role:'f_role', #only grant find privilege to the roleprivileges:[    {        resource:{db:'testdev',collection:'testcol'},        actions:['find']    }],roles:[]})

(2)grant a role to a user

db.grantRolesToUser(    'test_user',    [        {role:'role_name',db:'admin'},        'f_role' #only as illustration    ])

(3)update a role
for example, update existing role called cols_role with a new privilege

use testdevdb.updateRole('cols_role',{#as update document object    privileges:[        {            resource:{db:'testdev',collection:''},            actions:['listCollections']        }    ],    roles:[]})    

collection-level access control

sometimes, need to limit user operations to specific collections by specific privileges and scope.
for example, a user called test_user_1 with only has find and show collections privileges in testdev.

here, make an assumption that test_user_1 has been there, then grant two roles called f_role and cols_role to the user, that is it.

through simple action above, you have limited access to testdev db.

(Notes: the article mainly focuses on deploying test/dev environment locally, testing/verifying/contributing code for mongoengine. )