We need to run Exasol locally on M1 machines to support the local testing. However docker image does not start on Exasol.
Docker image used - https://github.com/exasol/docker-db/
Do we have any other workaround for this?
Tried using --platform flag already.
Tried building the original dockerfile using buildx on mac, but that also throws error.
The error -
[+] Building 3.1s (4/4) FINISHED
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 32B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 34B 0.0s
=> ERROR [internal] load metadata for docker.io/library/centos:7.5.1804 3.0s
=> [auth] library/centos:pull token for registry-1.docker.io 0.0s
------
> [internal] load metadata for docker.io/library/centos:7.5.1804:
------
error: failed to solve: rpc error: code = Unknown desc = failed to solve with frontend dockerfile.v0: failed to create LLB definition: no match for platform in manifest sha256:7a45e4a1efbaafc1d9aa89925b6fdb33288a96d35ea0581412316e2f0ad3720a: not found
Exasol does not officially support running its Docker image on Apple's M1 architecture. The error message shows that the system is not able to find a platform match for the image. As of now the Exasol docker image you're trying to run is built for x86_64 architecture.
An open issue is already registered here.
You can try running in a VMware or you need an Intel system to run.
Yes, Exasol does not officially support running its Docker image on Apple's M1 architecture. So no warranty at all.
The following steps worked once. Not sure if they will be helpful for a docker installation.
Downloaded the Exasol Community Edition OVA EXASOL-Single-Node-7.1.4.ova
Extracted the files to expose the virtual machine disk EXASolo-7.1.4-disk1.vmdk using the TAR command in terminal tar -xvf EXASOL-Single-Node-7.1.4.ova
Converted the virtual machine disk from VMDK to QCOW2 format using qemu-img (note: I installed qemu via brew to have access to this command but I think other options are available) qemu-img convert -O qcow2 EXASolo-7.1.4-disk1.vmdk EXASolo-7.1.4-disk1.qcow2
Setup the UTM configuration as:
System
Memory = 12288 MB
Show Advance Settings > UEFI Boot = FALSE, CPU = Icelake-Client, CPU Cores = 4, Force Multicore = TRUE
Drives
Import Drive > Browse and import the EXASolo-7.1.4-disk1.qcow2
New Drive > Interface = IDE and Size = 20GB
Start up the Virtual Machine in UTM and you should get a boot option for CentOS Linux, press enter and then it will start the boot process for the OS
Wait and you should see the familiar blue screen, this will show as "Initializing... Automatic refresh in 5 seconds" (this took about 5 minutes for me but your configuration could be different).
This is followed by "EXASolution will start soon... Automatic refresh in 5 seconds" continue to wait for the database to be operational (again this could take another 5-10 minutes, be patient as I had to learn!).
Finally you should see the configuration screen with details to connect to the Exasol database and EXAOperation confirming its ready to be used, woohoo!
Related
I have set up VON network on my device and currently trying to set up Permitify on Windows 10. After using ./mange build it will shows error like this:
failed to solve with frontend dockerfile.v0: failed to create LLB definition: docker.io/bcgovimages/von-image:py36-indy1.3.1-dev-441-ew-s2i: not found
Error image
using docker version 20.10.12
Any help is appreciated
I had the same error message after migrating from Docker Desktop to colima. My docker build was failing:
$ docker -v build . -f Dockerfile
[+] Building 0.2s (3/3) FINISHED
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 37B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> ERROR [internal] load metadata for docker.io/library/python:3.10-alpine 0.1s
------
> [internal] load metadata for docker.io/library/python:3.10-alpine:
------
failed to solve with frontend dockerfile.v0: failed to create LLB definition: rpc error: code = Unknown desc = error getting credentials - err: docker-credential-desktop resolves to executable in current directory (./docker-credential-desktop), out: ``
The error message I was receiving is similar to that received by the OC (wpj).
So I solved the problem by downloading the image again:
$ docker pull python:3.10-alpine
3.10-alpine: Pulling from library/python
213ec9aee27d: Already exists
47858aee13bf: Already exists
cfe0d6c6d05c: Already exists
2df617b3dcd9: Already exists
db25826960ff: Already exists
Digest: sha256:03504748146cea12539306ef7eea0983e282a335bdf565e6becc1bec8535b00f
Status: Downloaded newer image for python:3.10-alpine
docker.io/library/python:3.10-alpine
Even though the image was already local to my colima instance, there may have been a reference to Docker desktop meta-data that was causing the failure. The subsequent pull resulted in this being corrected.
A little bit more insight - my build was working well with colima until I delete Docker Desktop. Apparently, there was a metadata dependency that I was unaware of (but now can correct).
There is no tag on the bcgovimages/von-image image called py36-indy1.3.1-dev-441-ew-s2i on docker hub. It might have been removed and replaced with a newer one. I quickly tried finding one that looked like your tag, but didn't have any luck.
I'd try using bcgovimages/von-image:py36-1.16-1 since that's the newest one that starts with py36.
You can check what tags are available here: https://hub.docker.com/r/bcgovimages/von-image/tags?page=1
I am trying to create an image with my binary file (written in Rust) but I get different errors. This is my Dockerfile:
FROM scratch
COPY binary /
COPY .env /
COPY cert.pem /etc/ssl/
ENV RUST_BACKTRACE 1
CMD /binary
Building finishes fine but when I try to run it I get this:
$ docker run binary
docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"/bin/sh\": stat /bin/sh: no such file or directory": unknown.
ERRO[0000] error waiting for container: context canceled
And this:
$ docker run binary /binary
standard_init_linux.go:195: exec user process caused "no such file or directory"
I have no idea what to do. The error message looks very odd to me. According to the official Docker documentation it must work.
System info: latest Arch Linux and Docker:
Docker version 18.02.0-ce, build fc4de447b5
I tested with a C++ program and it works fine, with both clang and gcc.
It does not work with scratch, alpine, busybox ,or bash-based images, but it does work with postgresql, ubuntu, and debian images. The exact problem is something related to Rust and lightweight docker images - everything works okay otherwise.
As #Oleg Sklyar pointed out, the problem is that the Rust binary is dynamically-linked.
This may be a bit confusing because many people who have heard of Rust have also heard that Rust binaries are statically-linked, but this refers to the Rust code in crates: crates are linked statically because they are all known at the moment of compilation. This does not refer to existing C dynamic libraries that the program may link to, such as libc and other must-have libraries. Often times, these libraries can also be built as statically-linked artifacts (see the end of this post). To check whether your program or library is dynamically-linked, you can use ldd utility:
$ ldd target/release/t
linux-vdso.so.1 (0x00007ffe43797000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fa78482d000)
librt.so.1 => /usr/lib/librt.so.1 (0x00007fa784625000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fa784407000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fa7841f0000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fa783e39000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fa784ca2000)
You'll need these libraries in your Docker image. You will also need the interpreter; to get its path you can use objdump utility:
$ LANG=en objdump -s -j .interp target/release/t
target/release/t: file format elf64-x86-64
Contents of section .interp:
0270 2f6c6962 36342f6c 642d6c69 6e75782d /lib64/ld-linux-
0280 7838362d 36342e73 6f2e3200 x86-64.so.2.
Copy the files into the expected directories and everything works okay.
There is also a second option which is to use the rust-musl-builder docker image. There are some problems with postgresql and diesel but for most of projects it would be good. It works by producing a statically-linked executable which you may just copy and use. This option is much more preferred than using an interpreter and dynamic libraries if you want to provide a docker image with less size and without having all that useless extra data such as interpreter, unused libraries and so on.
In my case, the issue was that I was passing an invalid executable name:
CMD ["liquidator"]
liquidator was the name of the Docker image, but I needed this:
CMD ["hifi-liquidator"]
Basically the CMD must be the same as the "name" field in the Cargo.toml file.
According to the documentation at bazelbuild/rules_docker, it should be possible to work with these container images on OSX, and it also claims that it's possible to do so without docker.
These rules do not require / use Docker for pulling, building, or pushing images. This means:
They can be used to develop Docker containers on Windows / OSX without boot2docker or docker-machine installed.
They do not require root access on your workstation.
How do I do that? Here's a simple rule:
go_image(
name = "helloworld_image",
importpath = "github.com/nictuku/helloworld",
library = ":go_default_library",
visibility = ["//visibility:public"],
)
I can build the image with bazel build :helloworld_image. It produces a tar ball in blaze-bin, but it won't run it:
INFO: Running command line: bazel-bin/helloworld_image
Loaded image ID: sha256:08d312b529d30431c68741fd3a31468a02533f27a8c2c29eedc969dae5a39852
Tagging 08d312b529d30431c68741fd3a31468a02533f27a8c2c29eedc969dae5a39852 as bazel:helloworld_image
standard_init_linux.go:185: exec user process caused "exec format error"
ERROR: Non-zero return code '1' from command: Process exited with status 1.
It's trying to run the linux this is OSX, which is silly.
I also tried doing a "docker load" on the .tar content but it doesn't seem to like that format.
$ docker load -i bazel-bin/helloworld_image-layer.tar
open /var/lib/docker/tmp/docker-import-330829602/app/json: no such file or directory
Help? Thanks!
You are building for your host platform by default so you need to build for the container platform if you want to do that.
Since you are using a go binary, you can do cross compilation by specifying --cpu=k8 on the command line. Ideally we would be able to just say that the docker image needs a linux binary (so no need to specify the --cpu command-line flag) but this is still a work in progress in Bazel.
I am new to container world and exploring options to run my application on a container.Here are the things that I am seeing:
When I include compiling and building the C/C++ binary as part of docker image itself, it works fine with out any problems. Container starts and everything works fine.
If I try to run an already compiled and existing binary using CMD ["./helloworld"] in a container It throws me this error
standard_init_linux.go:185: exec user process caused “exec format error”.
Any ideas of how to get out of this problem? This seems like a basic problem that would have been solved already
Here is my dockerfile:
FROM ubuntu
COPY . /Users/test//Documents/CPP-Projects/HelloWorld-Static
WORKDIR /Users/test/Documents/CPP-Projects/HelloWorld-Static
CMD ["./build/exe/hellostatic/hellostatic"]
Hers is my exe:
gobjdump -a build/exe/hellostatic/hellostatic
build/exe/hellostatic/hellostatic: file format mach-o-x86-64
build/exe/hellostatic/hellostatic
Here is the error:
docker run test
standard_init_linux.go:185: exec user process caused “exec format error”
The problem is that you are trying to run an incompatible binary format in your container...
You are running an Ubuntu-based container (FROM ubuntu) line, but you are trying to run a Mach-O binary. By default, Linux will not run mach-o binaries.
Build your binary for the target platform (Ubuntu/Linux) and it will work well. It appears that you are running Mac OS X, so you could install an Ubuntu VM to compile your binary and transfer it to be used by the container.
When you build it inside the container, it works because it will be built to the right platform.
I have a suse linux 12 ec2 instance. I have activated a image sles11sp3-docker-image using sledocker. In the Dockerfile when I try to install ibm java 1.6 using
RUN zypper in java-1_6_0-ibm, I get following error .
Refreshing service 'container-suseconnect'.
Problem retrieving the repository index file for service 'container-suseconnect':
[|]
Skipping service 'container-suseconnect' because of the above error.
Warning: No repositories defined. Operating only with the installed resolvables. Nothing can be installed.
Loading repository data...
Reading installed packages...
'java-1_6_0-ibm' not found in package names. Trying capabilities.
Resolving package dependencies...
No provider of 'java-1_6_0-ibm' found.
Nothing to do.
The command '/bin/sh -c zypper in java-1_6_0-ibm' returned a non-zero code: 104
Please help
According to the docs (https://www.suse.com/documentation/sles-12/singlehtml/dockerquick/dockerquick.html), running zypper ref -s only gets you repo URLs with 12 hour tokens. Moreover, this command only appears to work while running in Docker on a SLES12 host.
Once I push the image to a repo and run it on another host, zypper ref -s no longer works (same error as yours). I'm basically stuck pre-installing all the base stuff before I publish the image.