The cloudfront we used for libraries doesn't work anymore

Kafka Connect
1

We recently started to receive the errors:

Could not resolve host: d1i4a15mxbxib1.cloudfront.net

In our Strimzi when building the KafkaConnectors - this hostname was appearing in the tutorials/documentation.

Any idea what has happened with it, how we should progress?

2

If this is not supposed to be stable link - any ideas, how to best ensure the stability/continuity?

3

Which tutorial / docs are you looking at?

Moving forward, I’d recommend using the Confluent CLI (confluent connect plugin install ..., doc here). You may have to install the CLI as a prereq.

4

Thanks dtroiano, probably they are no longer online on Confluent pages, but this one from blog also directly uses the not anymore working CDN: Using the Debezium MS SQL connector with ksqlDB embedded Kafka Connect

The issue is we build our KafkaConnect automatically via Strimzi which expects URLs to libraries we should be using: Configuring Strimzi (0.41.0) so I don’t see how we can install the CLI, this wouldn’t work in that workflow (so the issue is for production systems, not local experimentation/testing).

I guess we could explore Maven repository, but people also raised that it is not updated with the latest released artefacts: github .com /confluentinc/kafka-connect-storage-cloud/issues/758 (can’t post more than 2 links)

So I am a bit stumped how, what’s the best approach here outside the confluent platform…

5

If anyone else is encountering this we found a quick workaround:

Official connectors can be found here:
https://www.confluent.io/hub/confluentinc/kafka-connect-s3

To wget the connector we downloaded the connector & inspected the network tab which gives the command:
wget https://d2p6pa21dvn84.cloudfront.net/api/plugins/confluentinc/kafka-connect-s3/versions/10.5.13/confluentinc-kafka-connect-s3-10.5.13.zip

Whilst there is a version change it’s the best workaround we’ve found so far unless you’ve already saved the package in a S3 bucket etc to reference

6

Yes, we followed the same, but noticed the URL changed (I guess CDN), so I can imagine it’s not really expected way of using that…

Is really the answer to self-host those packages?