ARM64 support? about common-docker HOT 24 CLOSED

It will be great to get support for M1, because everyone is using M1 for work. It's very uncomfortable after 10 months of waiting to receive "segmentation fault" while other popular docker packages are already been ported to arm64...

from common-docker.

Hi Everyone, I'm one of the product managers at Confluent. The M1 problem is an interesting one and we have done some extensive analysis into the problem. It would be great if this was just a one-line change, but unfortunately, the docker on arm emulator (ARM QEMU) won't work. Based on what we are seeing in the Docker community, emulation is not viable.

Our only path forward is to ship Confluent Platform with formal ARM support, which we very much want to do and it's something on our backlog.

But this is a large amount of work and we don't take testing lightly. In the meantime, I recommend running an M1-supported hypervisor, using some cloud instances for development, or using Confluent Cloud basic clusters for development.

from common-docker.

Omg, one year after release apple silicon, and it still not working

from common-docker.

... and with all the server platforms also now becoming ARM based... ARM is becoming enterprise, not just a at home desktop toy...

from common-docker.

I am working on building confluentinc/kafka-image for both amd64 and arm64 platforms which uses confluentinc/common-docker as base image. It is failing with the below error while building this image on AMD64, using the command mentioned here.

WARNING: An illegal reflective access operation has occurred 
WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/usr/share/maven/lib/guice.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) 
WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1 
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations 
WARNING: All illegal access operations will be denied in a future release 
[INFO] Scanning for projects... 
[ERROR] [ERROR] Some problems were encountered while processing the POMs: 
[FATAL] Non-resolvable parent POM io.confluent:common:[7.1.0-0, 7.1.1-0) for io.confluent:common-docker:7.1.0-0: No versions matched the requested parent version range '[7.1.0-0, 7.1.1-0)' and 'parent.relativePath' points at wrong local POM @ io.confluent:common-docker:7.1.0-0, /home/ubuntu/ARM_FAAS_Project/subham/Docker/common-docker/pom.xml, line 7, column 13 
@ 
[ERROR] The build could not read 1 project -> [Help 1] 
[ERROR] 
[ERROR]   The project io.confluent:cp-base-new:7.1.0-0 (/home/ubuntu/ARM_FAAS_Project/subham/Docker/common-docker/base/pom.xml) has 1 error 
[ERROR]     Non-resolvable parent POM io.confluent:common:[7.1.0-0, 7.1.1-0) for io.confluent:common-docker:7.1.0-0: No versions matched the requested parent version range '[7.1.0-0, 7.1.1-0)' and 'parent.relativePath' points at wrong local POM @ io.confluent:common-docker:7.1.0-0, /home/ubuntu/ARM_FAAS_Project/subham/Docker/common-docker/pom.xml, line 7, column 13 -> [Help 2] 
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. 
[ERROR] Re-run Maven using the -X switch to enable full debug logging. 
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles: 
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException 
[ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException 

Can you please share the build process you are using to build these images?

Also, do you have any plans for releasing arm64 images?

from common-docker.

@jonstelly Jon, thank you for creating kymeric/cp-base.
If anyone needs an Arm64 schema-registry image that works on Arm64 I'd like to share my workaround.
Either you can build the image on your laptop replacing schema-registry Dockerfile in confluentinc/cp-docker-images with
https://gist.github.com/etolbakov/92c77f0c4cd4602afc7ce3800d5e1c65
or feel free to go with eugenetea/schema-registry-arm64:latest straightaway.

from common-docker.

It will be great to get support for M1, because for now it's working through amd64 and eats up a lot of memory...

from common-docker.

If anyone else is looking for a workaround, @jonstelly has prepared some arm64 kafka images that I found to be working nicely. I've replaced 'confluentinc/cp-kafka' with 'kymeric/cp-kafka' for my testcontainers tests and everything passed. More details here: confluentinc/cp-docker-images#830

from common-docker.

Just in case it’s helpful: I’ve been building my own images locally (and using them in my own docker-compose file) and they’re working well for me on my M1 Mac. They’re not nearly as sophisticated or configurable as the images produced by this repo, and right now they’ll only launch the broker and schema registry successfully, but these files (GitHub Gist) at the very least demonstrate a pattern that others could follow.

from common-docker.

@andrewegel are you the right person to ask about this? Are there any tasks you'd need help with to get this supported?

from common-docker.

Taking a PR to enable ARM build support at this time could have the unintended side effect of meaning that Confluent On Prem Docker Images supports ARM, but that (currently) would not be true from the business' perspective. I'm currently not aware of any sort of ARM support on Confluent's road map, but you're likely not the first or last to ask this question. I apologize that I can't definitively give you an answer in certain terms when (if) ARM support is coming, but the ARM architecture movement in the industry hasn't gone unnoticed by Confluent.

from common-docker.

@andrewegel can't there be a comment in the doc stating that ARM support is experimental and/or not official? that should be enough for now, I would think.

from common-docker.

@andrewegel can't there be a comment in the doc stating that ARM support is experimental and/or not official? that should be enough for now, I would think.

"I can't definitively give you an answer in certain terms when (if) ARM support is coming"

I'll also mention that these are Java services packaged in containers, there (shouldn't) be anything x86_64 specific in the docker files, and merely requires passing in the right platform arguments to the docker build process (not what this code base handles) to get them actually built.

from common-docker.

ARM support is also important for the osx m1 users with the new macbooks. Is there anything planned to support these devices or a workaround specific to the m1 macbooks?

from common-docker.

It almost wasted more than 15 days of my working effort. Is there any plan for the arm64?

from common-docker.

It does appear that installing plugins also fails on arm64.

I am attempting to install a Debezium plugin on the cp-kafka-connect-base image. The Debezium Postgres plugin will download correctly via confluent-hub, but will not load correctly:

[2021-07-15 02:50:39,770] INFO Loading plugin from: /usr/share/confluent-hub-components/debezium-debezium-connector-postgresql (org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader:246)
[2021-07-15 02:50:40,377] ERROR Stopping due to error (org.apache.kafka.connect.cli.ConnectDistributed:86)
java.lang.ExceptionInInitializerError
	at io.debezium.connector.postgresql.PostgresConnector.version(PostgresConnector.java:45)
	at org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader.versionFor(DelegatingClassLoader.java:387)
	at org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader.versionFor(DelegatingClassLoader.java:392)
	at org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader.getPluginDesc(DelegatingClassLoader.java:362)
	at org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader.scanPluginPath(DelegatingClassLoader.java:334)
	at org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader.scanUrlsAndAddPlugins(DelegatingClassLoader.java:268)
	at org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader.registerPlugin(DelegatingClassLoader.java:260)
	at org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader.initPluginLoader(DelegatingClassLoader.java:229)
	at org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader.initLoaders(DelegatingClassLoader.java:206)
	at org.apache.kafka.connect.runtime.isolation.Plugins.<init>(Plugins.java:61)
	at org.apache.kafka.connect.cli.ConnectDistributed.startConnect(ConnectDistributed.java:93)
	at org.apache.kafka.connect.cli.ConnectDistributed.main(ConnectDistributed.java:80)
Caused by: java.lang.NullPointerException: inStream parameter is null
	at java.base/java.util.Objects.requireNonNull(Objects.java:246)
	at java.base/java.util.Properties.load(Properties.java:406)
	at io.debezium.util.IoUtil.loadProperties(IoUtil.java:493)
	at io.debezium.util.IoUtil.loadProperties(IoUtil.java:523)
	at io.debezium.connector.postgresql.Module.<clinit>(Module.java:19)
	... 12 more

If I manually download the plugin's tar.gz and extract to /usr/share/confluent-hub-components, then the plugin will load correctly. However, then I get this different issue (Could not initialize class org.eclipse.jetty.http.MimeTypes$Type) when admin resources are added, and the connector does not start:

[2021-07-17 02:19:19,538] INFO Adding admin resources to main listener (org.apache.kafka.connect.runtime.rest.RestServer:241)
[2021-07-17 02:19:20,009] ERROR Stopping due to error (org.apache.kafka.connect.cli.ConnectDistributed:86)
java.lang.NoClassDefFoundError: Could not initialize class org.eclipse.jetty.http.MimeTypes$Type
	at org.eclipse.jetty.http.MimeTypes.<clinit>(MimeTypes.java:175)
	at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:895)
	at org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:288)
	at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
	at org.apache.kafka.connect.runtime.rest.RestServer.initializeResources(RestServer.java:305)
	at org.apache.kafka.connect.runtime.Connect.start(Connect.java:55)
	at org.apache.kafka.connect.cli.ConnectDistributed.startConnect(ConnectDistributed.java:140)
	at org.apache.kafka.connect.cli.ConnectDistributed.main(ConnectDistributed.java:80)
[2021-07-17 02:19:20,020] INFO Kafka Connect stopping (org.apache.kafka.connect.runtime.Connect:67)

As a sanity check, I switched to the Postgres plugin to the MySQL plugin, it will download and load correctly (using either confluent-hub), but the error above persists. Attempting to switch to Confluent's own JDBC connector plugin results in the same behaviour as well, whether it be installed using confluent-hub or manually downloaded and extracted.

There is a bit of back-and-forth in this community hub post.

Would be good if anyone can replicate on their M1 machine, and see if similar behaviour is observable.

TL;DR:

Open to any further ideas if anyone has any clues...

from common-docker.

Any update?

from common-docker.

localstack/localstack#4456 (comment)

I see an issue with alpine linux JDK on M1 with an illegal charset - that problem is afflicting confluent images

from common-docker.

... 2 wishes here also... want to build/deploy the entire cp stack on my to be MAC, currently have a i7, but about to pull the trigger on the new M1... so need a ARM compatible set of docker images for the CP stack and then #2... I'm looking at putting together a little lab at home out of 4 or 5 RPi4's with K8S deployed, on which I want to deploy the full stack also.
Connector capability (Redis, ElasticSearch, PostgreSQL & MysSQL at min) and schema manager is important.
G

from common-docker.

@andrewegel from your earlier message you stated the business currently doesn't have plans to widely announce ARM support - is this still the case?

from common-docker.

Hire me, and I make ARM support if you can't

from common-docker.

I know Mac M1 is the new hotness, so I thought I’d offer an alternative for folks who want to run Confluent on their macs instead of waiting for full ARM support. Try Gitpod to run code in the browser.

Here’s CP Demo running in gitpod: https://docs.confluent.io/platform/current/tutorials/cp-demo/docs/on-prem.html#gitpod

Heck, you can code on your iPad if you want.

from common-docker.

Locking the conversation to avoid repeated questions of "when will it come?" - Its in confluent's backlog to support, but there won't be any commitments to dates at this time.

How can we help?

Come work for us: https://www.confluent.io/careers/ - We have open positions for Developer Productivity & Release Engineering that we need filled! More help to churn through Confluent's backlog of work such as this.

from common-docker.

Hi folks,

Confluent has released Docker images for arm64 for development and testing purposes. Check it out across different Confluent Platform components in Docker Hub: https://hub.docker.com/u/confluentinc

For example, here’s how to pull the latest CP Kafka image, and the appropriate image dependent on OS architecture type (amd64 or arm64) will be pulled down:

docker pull confluentinc/cp-kafka:latest

from common-docker.