add binary/docker images for darwin amd64 & arm64

[tasdflkjweio]

I've just pulled down docker images versions 1.16.4-arm64 and 1.17.0-arm64 for testing purposes on my M1 Macbook Pro, and am getting this error when running either of them:

docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "/chproxy": stat /chproxy: no such file or directory: unknown.

I've tried a couple different configurations (pulled directly from the Chproxy website) with the docker installation command (also pulled from the website):

$ docker run -d -v /Users/myuser/working/chproxy/config.yml:/config.yml contentsquareplatform/chproxy:1.16.4-arm64 -config /config.yml

The error reads perhaps as though the entrypoint is not being found. Any thoughts on where to go from here?

[mga-chka]

We recently released arm based docker build but weren't able to test it on our laptop since we're using Intel based CPU so it might be a bug from our image. @sigua-cs , do you think you could check it using an AWS ARM based instance (graviton) just to validate the docker image ?

[tasdflkjweio]

Thanks for the quick response. I've tried pulling down the equivalent arm64 binaries as well, and am not having any luck there either.

$ ./chproxy-arm64 -config ./config.yml 
zsh: exec format error: ./chproxy-arm64

I believe the binary is unrecognizable.

[mga-chka]

It's weird because I quickly checked on a personal ARM instance hosted on Oracle cloud and didn't have an issue with the binary:

$ wget https://github.com/ContentSquare/chproxy/releases/download/v1.17.0/chproxy_1.17.0_linux_arm64.tar.gz
$ gunzip chproxy_1.17.0_linux_arm64.tar.gz
$ tar -xvz chproxy_1.17.0_linux_arm64.tar
$ echo 'log_debug: true
hack_me_please: true
caches:
  - name: fscache
    mode: "file_system"
    file_system:
       dir: "/tmp/"
       max_size: 1500Mb
    expire: 130s
users:
  - name: user
    password: pwd
    to_cluster: local
    to_user: default
    cache: fscache
    max_concurrent_queries: 2
    max_execution_time: 30s
clusters:
  - name: local
    scheme: http
    nodes:
      - 127.0.0.1:8123
    users:
      - name: default
server:
  http:
      listen_addr: ":9090"
      allowed_networks: ["127.0.0.0/24"]' > conf.yml
      
$ ./chproxy-arm64  -config conf.yml 
INFO: 2022/08/31 17:39:11 main.go:46: chproxy ver. 1.17.0, rev. edf42ff892fde4ef2a4002ffc6707025f2479d84, built at 2022-08-29T18:13:04Z
INFO: 2022/08/31 17:39:11 main.go:47: Loading config: conf.yml
DEBUG: 2022/08/31 17:39:11 transaction_registry_inmem.go:34: inmem transaction: cleaner start
DEBUG: 2022/08/31 17:39:11 filesystem_cache.go:236: cache "fscache": start cleaning dir "/tmp/"
DEBUG: 2022/08/31 17:39:11 filesystem_cache.go:312: cache "fscache": final size 0; final items 0; removed size 0; removed items 0
DEBUG: 2022/08/31 17:39:11 filesystem_cache.go:315: cache "fscache": finish cleaning dir "/tmp/"
INFO: 2022/08/31 17:39:11 main.go:280: Loaded config:
server:
  http:
    listen_addr: :9090
    allowed_networks:
    - 127.0.0.0/24
    forceautocerthandler: false
    read_timeout: 1m
    write_timeout: 90s
    idle_timeout: 10m
clusters:
- name: local
  scheme: http
  nodes:
  - 127.0.0.1:8123
  users:
  - name: default
    password: XXX
  heartbeat:
    interval: 5s
    timeout: 3s
    request: /ping
    response: |
      Ok.
users:
- name: user
  password: XXX
  to_cluster: local
  to_user: default
  max_concurrent_queries: 2
  max_execution_time: 30s
  cache: fscache
log_debug: true
hack_me_please: true
caches:
- mode: file_system
  name: fscache
  expire: 130s
  file_system:
    dir: /tmp/
    max_size: 1572864000
INFO: 2022/08/31 17:39:11 main.go:55: Loading config "conf.yml": successful
INFO: 2022/08/31 17:39:11 main.go:160: Serving http on ":9090"

The only difference is see is that I'm using bash and you zsh (and I'm running on ubuntu).

[tasdflkjweio]

Sorry for the delayed response. I tried the exact same commands and get the same error. I had a friend - also with an M1 MBP - pull down and try, and he's getting the exact same thing as me.

[mga-chka]

ok, this one might take time because we need to get a M1 MBP to understand the issue:-/. I'll try to bother someone with a M1 MBP when I can.

[mga-chka]

I think I got the issue, our builds only work for linux. https://github.com/ContentSquare/chproxy/blob/master/.goreleaser.yml#L28

We will need to add a specific build for macOS/darwin. I'll change the name of the issue and tag it as feature request

[mga-chka]

FYI @sigua-cs is currently looking at adding macOS builds for chproxy binaries & docker images

[tasdflkjweio]

appreciate the update!

[sigua-cs]

Hello @tasdflkjweio , I created a PR https://github.com/ContentSquare/chproxy/pull/239 which partially implements this issue. I'll be working on docker images in a separate task/pr. I'll keep you posted on it

[sigua-cs]

Hello @tasdflkjweio, I'm closing this issue since you can find Docker images for multiple platforms in our DockerHub. The latest version, v1.19.0-arm64v8 includes the fix you mentioned in this PR. For M1, you can use v1.19.0-arm64v8, which I tested on my MBP M1.

Please note In the previous versions, we used the Arch suffix for the binary names in the Docker images. We fixed this. So today, it's the same binary name for all Arch which is available in the root directory /chproxy.

Feel free to reopen this issue and tag me if you have any questions about this subject.