# get image
docker pull ibmcom/mq
# create volume to sore settings and messages
docker volume create qm1data
# run container without default mq_dev config and attach the new volume
docker run --env LICENSE=accept --env MQ_QMGR_NAME=QM1 --env MQ_DEV=false --publish 1414:1414 --publish 9443:9443 --detach --volume qm1data:/mnt/mqm ibmcom/mq
# login to web console
Step 2 – Disable security
The default configuration has security configured out of the box. And that is a good thing! But it might be a bit annoying for local development.
Connect to your container using the cli. Use runmqsc to disable security and create a new channel that runs under the mqm user.
ALTER QMGR CHLAUTH (DISABLED)
ALTER QMGR CONNAUTH(' ')
REFRESH SECURITY TYPE(CONNAUTH)
define channel(DEMO.ADMIN.SVRCONN) chltype(SVRCONN) trptype(TCP) mcauser('mqm')
At this point, security is disabled and the channel “DEMO.ADMIN.SVRCONN” can be used for messaging (from Java / .NET) and admin purposes (MQ Explorer) without any security.
DISCLAIMER: you should only disable security like this in a development scenario!
When working in a corporate context, you often get confronted with a corporate web proxy. This can become very annoying when working with various command-line tools that have issues with the authentication part of that web proxy.
Luckily, Cntlm can remove that friction by running a local proxy without authentication, that authenticates to the actual proxy for you.
The course is focused on using an Ubuntu test server for Kafka and a Java development environment. This blog post is a list of resources that I found helpful while exploring Apache Kafka, with a focus on the Microsoft stack.
Hosting a Kafka environment
Multiple options exist for hosting your test environment. One option is to deploy Apache Kafka in an Azure HDInsight cluster (quickstart tutorial + Azure Friday). This option seemed a bit overkill for me as I was searching a “quick start” experience.
Another option are containers. While searching for Docker images, I stumbled upon the Bitnami Kafka Stack. They offer both Docker and VM images that you can use for running locally on your machine or for deploying to the Azure cloud (Bitnami Azure Marketplace).
But, also this still takes some time before you can connect to your Kafka test cluster. So in the end, I went for a Confluent Kafka cluster, running in Azure. It took me less then 3 minutes to register a new Confluent account, create a new Kafka cluster and connect to it with Conduktor. This solution is of course not free. Luckily, it is possible to use the Confluent platform for 3 months with a 50 USD spending credit per month.
Connecting to Kafka from .NET
When it comes to connecting to Kafka with .NET, there is only one solution you should use and that is “confluent-kafka-dotnet“. All other packages are outdated and suggest you should use that one.