Get Started With Db2 In Minutes
Db2 has moved away from Docker Hub and 11.5.9 just GA’d! Now what?
For years, containerized images of Db2 were available from Docker Hub and could be deployed in minutes using a single command. That was great but the use of that container registry has been deprecated and will be entirely sunset in the future. On top of that, more and more people are migrating from docker
to podman
so… can you still get up & running in minutes? Yes.
IBM now provides its own home for container images — IBM Container Registry — icr.io — a more secure, and less rate-limited, home.
If containers aren’t your thing, there are many other ways to get your hands on this mission-critical, always-on data server, from downloadable software packages, to cloud services, and even Kubernetes/OpenShift options. I’ll talk about more of those another time.
If you’re interested in trying Db2 in a container, on x86_64 Linux for the moment, here we go…
Getting the Db2 Community Edition Container
There are slightly different instructions needed for other containerized Db2 offerings, including Db2U and Db2 Warehouse. For now, let’s focus on Db2 Community Edition.
First, you need to create a persistent home for the database storage outside of the container. That’s necessary for the container startup so make a simple directory for that.
After that, it’s just one command to get started. It is a big command so let’s break it down a bit:
mkdir ~/db2cont
podman run -it \
--hostname=db2host \
--name db2server \
--detach \
--publish 50000:50000 \
--privileged=true \
--volume ~/db2cont:/database \
--env DB2INSTANCE=db2inst1 \
--env DB2INST1_PASSWORD=password \
--env LICENSE=accept \
--env DBNAME=mydb \
icr.io/db2_community/db2
That’s it. Your mileage will vary but on a reasonably fast network this can complete in just 1–2 minutes. Sorry, not even enough time to get coffee but… it’s not quite done yet!
Behind the scenes, the first time the container is started, scripts within the container are now creating and configuring the database as you specified (called MYDB in this case) so you’ll need to watch the output logs of the container and wait until it’s ready, like this:
podman logs -f db2server
Wait until you see the following messages near the end of the log output, then <CTRL>+c to stop watching and move on.
(*) All databases are now active.
(*) Setup has completed.
What did all those options do?
If you’re familiar with Docker or Podman most of those options probably made sense but if not:
-i : Keeps stdin open, allowing an interactive session, sending cmds
-t : Allocate a pseudo-tty to attach to stdin of the container
--hostname : Set the host name, available inside the container
--name : Set a container name, as a nice alternative to a random UUID
--detach : Run in the background and just show the new container ID
--publish : Publish a container's port to the host
--privileged : Run with less isolation and give access to devices
--volume : Bind mount a path within the container to a host path
--env : Set an environment variable to be available in the container
It’s worth mentioning that there are a number of additional environment variables that could have been specified to further customize and configure the Db2 instance and database. Have a look through this section of the Db2 Knowledge Center for more details.
Getting Useful
You’re now up and running but how do you give it useful work to do?
To view the containers you currently have executing, use podman ps
. It shows a number of important pieces of information, including (scroll way over to the right) the name we specified during podman run:
> podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a1ed4ce23f03 icr.io/db2_community/db2:latest 3 minutes ago Up 3 minutes 0.0.0.0:50000->50000/tcp db2server
We can do all sorts of useful things with this now but for example, to enter the container and launch a Bash shell as the Db2 instance userid so we can run Db2 commands, just:
podman exec -it db2server bash -c "su - db2inst1"
Voila! You are now executing a bash
shell inside the Db2 container called db2server
, executing as the Db2 instance owner, db2inst1.
From here it’s simple to issue commands via the Db2 command line processor (CLP). You can view what the container has already created for you, and confirm that it did create a database of the name you asked for:
[db2inst1@db2host ~]$ db2 list db directory
System Database Directory
Number of entries in the directory = 1
Database 1 entry:
Database alias = MYDB
Database name = MYDB
Local database directory = /database/data
Database release level = 15.00
Comment =
Directory entry type = Indirect
Catalog database partition number = 0
Alternate server hostname =
Alternate server port number =
Next, connect to it and create whatever tables and other SQL objects you wish:
[db2inst1@db2host ~]$ db2 connect to mydb
Database Connection Information
Database server = DB2/LINUXX8664 11.5.8.0
SQL authorization ID = DB2INST1
Local database alias = MYDB
[db2inst1@db2host ~]$ db2 create table t1 "(c1 char(1), c2 char(1), c3 char(1))"
DB20000I The SQL command completed successfully.
[db2inst1@db2host ~]$ db2 insert into t1 values "('I', 'B', 'M')"
DB20000I The SQL command completed successfully.
[db2inst1@db2host ~]$ db2 select \* from t1
C1 C2 C3
-- -- --
I B M
1 record(s) selected.
What Else Do We Know About This Database?
If you poke around a bit, checking the database configuration you’ll find that you’ve been handed a rollforward recoverable, row-organized (by default database) with its contents and transaction logs stored under/database
of the container (which we mapped to ~/db2cont
) in our home directory.
A very first, offline DB backup has already been produced and exists in /database/backup
, and the database contents and user data exist beneath /database/data
.
[db2inst1@db2host ~]$ db2 get db cfg for mydb | grep LOGARCHMETH
First log archive method (LOGARCHMETH1) = DISK:/database/logs/
Second log archive method (LOGARCHMETH2) = OFF
[db2inst1@db2host ~]$ ls /database/*
/database/backup:
MYDB.0.db2inst1.DBPART000.20231113220300.001
/database/config:
db2fenc1 db2inst1 global.reg instance.cfg licenses
/database/data:
db2inst1
/database/logs:
db2inst1
That’s it. Db2 is up & running so go experiment and enjoy.
Tidying Up
You can exit from the Bash shell at any time, the container will keep running and you can always re-enter using the same command as before.
Shutting down the running container is also easy. From outside the container:
podman stop db2server
Later, you can view all available containers, running or stopped, and restart a previously stopped container:
> podman container list -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
671075fbe240 icr.io/db2_community/db2:latest 3 days ago Exited (0) 8 minutes ago 0.0.0.0:50000->50000/tcp db2server
> podman start db2server
db2server
> podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
671075fbe240 icr.io/db2_community/db2:latest 3 days ago Up 8 seconds 0.0.0.0:50000->50000/tcp db2server
icr.io Registry Contents
You can also view the contents of the container registry and see all available Db2 images using a tool such as skopeo
. Here we can see that the most recent Db2 11.5 mod pack updates are available as images:
> skopeo list-tags docker://icr.io/db2_community/db2
{
"Repository": "icr.io/db2_community/db2",
"Tags": [
"11.5.5.1",
"11.5.7.0a",
"11.5.8.0",
"11.5.9.0",
"latest"
]
}
Last but not least, if you just want to fetch a copy of an image, without also creating a container layer and running it, that’s also possible:
podman pull icr.io/db2_community/db2
Enjoy!