Chad Scott 110000E1UB Visits (4191)
One of the biggest hurdles for adopting Connections Pink on-prem is getting your arms around the new Kubernetes technology stack. In the beginning, even basic tasks like collecting logs will generally cause you to turn to scouring the internet, often without the basic vocabulary needed to find what you're looking for. I know because I've been there.
That struggle led me to create some simple scripts to help. When I'd learn a command for a particular task, I'd turn that into a rudimentary script to help with the next time I needed to perform the same task. Over time, these scripts grew in function and became my primary interface for working with Connections Pink. I've made the tooling available as part of the Conn
One of the first things you'll notice when working with Connections Pink is that doing anything useful will typically require the name of a pod to operate on. In the world of pods, we typically don't care which pod we're working on, but we do need the full name of a pod to do things like collect logs or print configuration details. The out-of-the-box way to get a full pod name is to use kubectl like so:
$ sudo kubectl get pods -n connections -o wide
This will print terse information about all pods, one per line. From there you can get the full name of any pod in the first column. You can even take this to the next level by piping the output to grep so that you only see the names of the pods you're interested in. Picking on orient-web-client, that would look something like this:
$ sudo kubectl get pods -n connections -o wide | grep orient-web-client
$ pod=$(sudo getPodName.sh orient-web-client) $ echo $pod orie
The first line runs the getPodName.sh tool, passing in the friendly portion of the pod name that you'll be able to remember. This is wrapped in the $() syntax, which means its output is captured and stored in the pod variable. This pod variable can then be used in place of the full name wherever you need it. This way, you never need to remember or type the random characters after the friendly name. If necessary, you can specify the number of the pod you want. Have a look at the documentation for details.
Now that you have a reference to the pod, you could be content to simply substitute it for the full pod name when using the out-of-the-box kubectl commands. That's fine, and it will work great. For example:
$ sudo kubectl logs -n connections $pod
But here you still have to remember the format of the kubectl command, including the namespace option that I habitually omit. And what about logs that have rotated out to disk? Where are they? Our second tool, getPodLogs, solves issues like those.
$ sudo getPodLogs.sh $pod
As you can see from the output, you have both the contents of the active log printed to the console and pointers to the location of the rotated logs on disk.
The final tool we'll take a look at in this primer is connectToRedis, which opens a Redis CLI session. You may want to connect to Redis to verify events are flowing from Connections Blue to Connections Pink. This tool makes it trivially easy:
$ sudo connectToRedis.sh Connecting to redis-server-0... Common Redis commands: client list: List client connections info: Print server information keys <pattern>: List all keys matching the pattern monitor: Stream all requests received by the server pubsub channels: List active channels subscribe <channel>: Stream messages published to the given channel quit: Close the connection 127.0.0.1:6379>
From here, you can invoke any Redis commands necessary to perform your troubleshooting. I've even included a header of common commands as a cheat sheet. For myself. Because I can't remember.
Hopefully this has been a useful introduction to some of the functionality available in Conn