DB Dev Test Environment

[mccoc12]

Now that we have the base of the DB prod machines, we need to upload all the data to it. Copy over the databases, create users and copy over the programming checkpoint tool. We want these machines to be the same as if we just made a straight replica of the prod machines. you have access to the prod, as well as the original machines to copy from.

• [x] db2-mariadb
• [x] dev-db3-docker
• [x] db2-replicavm

[s-winton]

• production db2-mariadb scripts are in the home directory, sakila.sql, weather.sql, world.sql

Update on this: so some of the replica machines (not DB3 docker) had some weird azure networks attached to it. I tried changing the NSG setting to try and access those VMs to no avail, my NSG rules weren't being deployed to the mariadb and db2 replica VMs, so basically I deleted those replica VMS, snapshotted the production OS disks and re-deployed the replica VMs in the dev-db resource group.

[ZachariahPepper]

The currently running Disk on the DB3 server is db3docker-osdisk-20210902-011608. We are creating a snapshot based off this disk, as we cannot get access to the Dockerfile as it requires root user access to that directory. itintern does not have the permissions for this action.

[eadsysadmin]

Root user access can be obtained from ITIntern. Try running the "sudo su" command and then accessing the Dockerfile

[westcl4]

We created a new disk from a snapshot of the currently running production server and attached it to the dev-db3-docker VM. We did this before seeing @eadsysadmin 's message above. We have successfully tested that Docker works by running the hello-world container and it returned the success message.