I have a problem in opening minio in the browser. I just created Spring Boot app with the usage of it.
Here is my application.yaml file shown below.
server:
port: 8085
spring:
application:
name: springboot-minio
minio:
endpoint: http://127.0.0.1:9000
port: 9000
accessKey: minioadmin #Login Account
secretKey: minioadmin # Login Password
secure: false
bucket-name: commons # Bucket Name
image-size: 10485760 # Maximum size of picture file
file-size: 1073741824 # Maximum file size
Here is my docker-compose.yaml file shown below.
version: '3.8'
services:
minio:
image: minio/minio:latest
container_name: minio
environment:
MINIO_ROOT_USER: "minioadmin"
MINIO_ROOT_PASSWORD: "minioadmin"
volumes:
- ./data:/data
ports:
- 9000:9000
- 9001:9001
I run it by these commands shown below.
1 ) docker-compose up -d
2 ) docker ps -a
3 ) docker run minio/minio:latest
Here is the result shown below.
C:\Users\host\IdeaProjects\SpringBootMinio>docker run minio/minio:latest
NAME:
minio - High Performance Object Storage
DESCRIPTION:
Build high performance data infrastructure for machine learning, analytics and application data workloads with MinIO
USAGE:
minio [FLAGS] COMMAND [ARGS...]
COMMANDS:
server start object storage server
gateway start object storage gateway
FLAGS:
--certs-dir value, -S value path to certs directory (default: "/root/.minio/certs")
--quiet disable startup information
--anonymous hide sensitive information from logging
--json output server logs and startup information in json format
--help, -h show help
--version, -v print the version
VERSION:
RELEASE.2022-01-08T03-11-54Z
When I write 127.0.0.1:9000 in the browser, I couldn't open the MinIo login page.
How can I fix my issue?
The MinIO documentation includes a MinIO Docker Quickstart Guide that has some recipes for starting the container. The important thing here is that you cannot just docker run minio/minio; it needs a command to run, probably server. This also needs to be translated into your Compose setup.
The first example on that page breaks down like so:
docker run \
-p 9000:9000 -p 9001:9001 \ # publish ports
-e "MINIO_ROOT_USER=..." \ # set environment variables
-e "MINIO_ROOT_PASSWORD=..." \
quay.io/minio/minio \ # image name
server /data --console-address ":9001" # command to run
That final command is important. In your example where you just docker run the image and get a help message, it's because you omitted the command. In the Compose setup you also don't have a command: line; if you look at docker-compose ps I expect you'll see the container is exited, and docker-compose logs minio will probably show the same help message.
You can include that command in your Compose setup with command::
version: '3.8'
services:
minio:
image: minio/minio:latest
environment:
MINIO_ROOT_USER: "..."
MINIO_ROOT_PASSWORD: "..."
volumes:
- ./data:/data
ports:
- 9000:9000
- 9001:9001
command: server /data --console-address :9001 # <-- add this
Related
I wanted to test a container locally before pushing it to aws ecs.
I ran unit tests against a docker-compose stack including a dynamodb-local container using a Go (aws-sdk-go-v2) endpoint resolver with http://localhost:8000 as the url.
So I wanted to build and test container locally and realised I needed to attach it to the default network created by docker-compose. I struggled with this a bit so I build a stripped down trial. I created an endpoint resolver with a url of http://dynamo-local:8000 (named the container dynamo-local in d-c) and attached it to the default network within docker run.
Now that all works, I can perform the various table operations successfully, but one of the things that confuses me is that if I run aws cli:
aws --endpoint-url=http://localhost:8000 dynamodb list-tables
then the output shows no tables exist when there is definitely a table existing. I had assumed, naively, that as I can access port 8000 of the same container with different endpoints I should be able to access the same resources. Wrong.
Obviously a gap in my education. What am I missing ? I need to expand the trial to a proper test of the full app, so its important to me that I understand what is going on here.
Is there a way I can use the aws cli to access the table?
docker-compose file :
version: '3.5'
services:
localstack:
image: localstack/localstack:latest
container_name: localstack_test
ports:
- '4566:4566'
environment:
- SERVICES=s3,sns,sqs, lambda
- DEBUG=1
- DATA_DIR=
volumes:
- './.AWSServices:/tmp/AWSServices'
- '/var/run/docker.sock:/var/run/docker.sock'
nginx:
build:
context: .
dockerfile: Dockerfile
image: chanonry/urlfiles-nginx:latest
container_name: nginx
ports:
- '8080:80'
dynamodb:
image: amazon/dynamodb-local:1.13.6
container_name: dynamo-local
ports:
- '8000:8000'
networks:
default:
name: test-net
I ran into this "java.net.UnknownHostException: host.docker.internal: Name or service not known" problem when deploying a dockerized spring boot application on an AWS EC2 T2.micro instance. The spring boot application failed to start because of this error.
But the weird part is, I did not use the variable "host.docker.internal" anywhere in my application: not in the code, not in the yaml file, not in the .env file:
$ sudo grep -Rl "host.docker.internal" ~
/home/ec2-user/.bash_history
And when I run the following command it shows nothing but previous command to search for it:
$ cat /home/ec2-user/.bash_history | grep "host.docker.internal"
Locally I am using Windows 10 for development, and I can successfully bring up the stack with docker-compose.
Here is the EC2 instance OS version info:
$ cat /etc/*release
NAME="Amazon Linux"
VERSION="2"
ID="amzn"
ID_LIKE="centos rhel fedora"
VERSION_ID="2"
PRETTY_NAME="Amazon Linux 2"
ANSI_COLOR="0;33"
CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2"
HOME_URL="https://amazonlinux.com/"
Amazon Linux release 2 (Karoo)
And here is the docker-compose file that I used on the EC2 instance:
version: '2'
services:
backend:
container_name: backend
image: 'dockerhubuser/backend:0.0.4'
ports:
- '8080:8080'
volumes:
- /var/log/backend/logs:/var/log/backend/logs
- ./backend-ssl:/etc/ssh/backend
env_file:
- .env
depends_on:
- mysql
- redis
redis:
container_name: redis
image: 'redis:alpine'
ports:
- '6379:6379'
volumes:
- $PWD/redis/redis-data:/var/lib/redis
- $PWD/redis/redis.conf:/usr/local/etc/redis/redis.conf
mysql:
container_name: mysql
image: 'mysql:8.0.21'
ports:
- '3306:3306'
environment:
MYSQL_DATABASE: dbname
MYSQL_USER: dbuser
MYSQL_PASSWORD: dbpass
MYSQL_ROOT_PASSWORD: dbrootpass
volumes:
- ./my_volume/mysql:/var/lib/mysql
volumes:
my_volume:
And here is my .env file on the EC2 instance:
SERVER_PORT=8080
KEY_STORE=/etc/ssh/backend/keystore.p12
KEY_STORE_PASSWORD=keystorepass
REDIS_HOST=redis
REDIS_PORT=6379
DB_HOST=mysql
DB_PORT=3306
DB_USERNAME=dbuser
DB_PASSWORD=dbpass
I am pretty sure that this .env file is being used when bringing up the stack with "docker-compose up" because I can see the SERVER_PORT in the log matches this file when I change it.
2021-01-02 20:55:44.870 [main] INFO o.s.b.w.e.tomcat.TomcatWebServer - Tomcat initialized with port(s): 8080 (https)
But I keep getting the error complaining about "host.docker.internal".
Here are things that I have tried but not working:
Hard-code the db host in property spring.datasource.url in application.yml
Add the following entry to /etc/hosts file (see https://stackoverflow.com/a/48547074/1852496)
172.17.0.1 host.docker.internal
Add the following entry to /etc/hosts file, where "ip-172-31-33-56.us-east-2.compute.internal" is what I got when running command "echo $HOSTNAME"
ip-172-31-33-56.us-east-2.compute.internal host.docker.internal
Terminate the instance and created another T2.micro instance, but got same result.
Edit inbound rules to allow TCP:3306 from anywhere.
Can someone take a look? Any help appreciated.
It works on Ubuntu 20.04 after adding "172.17.0.1 host.docker.internal" to /etc/hosts file.
Make sure the docker engine version is 20.10-beta1 or newer.
So, I searched around for an answer on this matter but either people don't address the issue or they say there's no problem doing this on their computer (mac or linux). It seems like this might be a windows problem.
I have a spring api running on a docker container (linux container). I use docker desktop on windows and I'm trying to make a request (in insomnia/postman/wtv) to that api.
If I run the api locally making the following request works perfectly:
http://localhost:8080/api/task/
This will list multiples task elements.
I've containerized this application like so:
Dockerfile
FROM openjdk:11.0.7
COPY ./target/spring-api-0.0.1-SNAPSHOT.jar /usr/app/
WORKDIR /usr/app
RUN sh -c 'touch spring-api-0.0.1-SNAPSHOT.jar'
ENTRYPOINT ["java", "-jar", "spring-api-0.0.1-SNAPSHOT.jar"]
docker-compose.yml
version: '3.8'
services:
api:
build: .
depends_on:
- mysql
environment:
- SPRING_DATASOURCE_URL=jdbc:mysql://mysql:3306/test?createDatabaseIfNotExist=true
ports:
- "8080:80"
mysql:
image: mysql
ports:
- "3306:3306"
environment:
- MYSQL_ROOT_PASSWORD=root
- MYSQL_USER=root
- MYSQL_PASSWORD=root
- MYSQL_DATABASE=test
If I do docker-compose up this works without issue:
The problem is, if I try to call the same endpoint as before from localhost I don't get any response.
Insomnia returns an error saying: Error: Server returned nothing (no headers, no data)
I've also tried connecting to the container's ip (got it from docker inspect) but no luck.
Ports are exposed in docker-compose.yml. What am I missing?
Thanks in advance.
Port mapping is incorrect.Spring boot application started at 8080 (from the image I see) inside container and it should be mapped to 8080 inside the container.
It should be like below:
ports:
- "8080:8080"
I have 3 dockerized services. Services A and B run inside same docker-compose file:
docker-compose.yml
version: '3.5'
services:
service_a:
container_name: service_a
networks:
- my_net
service_b:
container_name: service_b
networks:
- my_net
networks: #This is just because I wanted to change the network default name
my_net:
name: my_net
Service C needs make requests against services A and B, but it runs separately using docker without compose (that's because I'm passing --network option). So, I run service C linking A and B:
docker run --network my_net --link service_a --link service_b service_c_docker_image
This is working on MacOS, but not in Ubuntu!
If I run ping command, instead of default service_c_docker_image command:
docker run --network my_net --link service_a --link service_b service_c_docker_image ping service_a
on MacOS, the host is reached properly; on Ubuntu, I get: ping: service_a: Name or service not known. And same with service_b.
Both machines are using same version of docker and docker-compose.
What am I missing?
You may have a typo in your question as that compose file should not run at all, the service level network names my_net should match the top level network name which then can be renamed using name: intra_net. The network set in the docker run command should match what the network was renamed to in the top level networks section (and that network needs to already exist, so run the compose stack first).
working example:
docker-compose.yaml
version: '3.5'
services:
service_a:
image: odise/busybox-curl
command: ["curl", "-s", "service_b:5678"]
depends_on:
- service_b
networks:
- my_net
service_b:
image: hashicorp/http-echo
command: ["-text", "hello world"]
networks:
- my_net
networks:
my_net:
name: infra_network
Run the services docker-compose up -d and check the logs:
> docker-compose logs
Attaching to docker-compose-networks_service_a_1, docker-compose-networks_service_b_1
service_b_1 | 2019/01/06 05:53:55 Server is listening on :5678
service_b_1 | 2019/01/06 05:53:55 service_b:5678 172.19.0.3:46900 "GET / HTTP/1.1" 200 12 "curl/7.39.0" 106.6µs
service_a_1 | hello world
Then start the other container with docker
> docker run --network infra_network odise/busybox-curl curl -s service_b:5678
hello world
Silly me. Actually, my configuration is right but services A and B were not run because an application level error, so links were not working.
I think this might be related to file system incompatibility (nfts/ext*)
How can I compose my containers and persist the db without the container exiting?
I'm using the bitnami-mongodb-image
Error:
Error executing 'postInstallation': EACCES: permission denied, mkdir '/bitnami/mongodb'
mongodb_1 exited with code 1
Full Output:
Recreating mongodb_1 ... done
Starting node_1 ... done
Attaching to node_1, mongodb_1
mongodb_1 |
mongodb_1 | Welcome to the Bitnami mongodb container
mongodb_1 | Subscribe to project updates by watching https://github.com/bitnami/bitnami-docker-mongodb
mongodb_1 | Submit issues and feature requests at https://github.com/bitnami/bitnami-docker-mongodb/issues
mongodb_1 |
mongodb_1 | nami INFO Initializing mongodb
mongodb_1 | mongodb INFO ==> Deploying MongoDB from scratch...
mongodb_1 | Error executing 'postInstallation': EACCES: permission denied, mkdir '/bitnami/mongodb'
mongodb_1 exited with code 1
Docker Version:
Docker version 18.06.0-ce, build 0ffa825
Windows Version:
Microsoft Windows 10 Pro
Version 10.0.17134 Build 17134
This is my docker-compose.yml so far:
version: "2"
services:
node:
image: "node:alpine"
user: "node"
working_dir: /home/node/app
environment:
- NODE_ENV=development
volumes:
- ./:/home/node/app
ports:
- "8888:8888"
command: "tail -f /dev/null"
mongodb:
image: 'bitnami/mongodb'
ports:
- "27017:27017"
volumes:
- "./data/db:/bitnami"
- "./conf/mongo:/opt/bitnami/mongodb/conf"
I do not use Windows but you can definitely try to use a named volume and see if the permission problem goes away
version: "2"
services:
node:
image: "node:alpine"
user: "node"
working_dir: /home/node/app
environment:
- NODE_ENV=development
volumes:
- ./:/home/node/app
ports:
- "8888:8888"
command: "tail -f /dev/null"
mongodb:
image: 'bitnami/mongodb'
ports:
- "27017:27017"
volumes:
- mongodata:/bitnami:rw
- "./conf/mongo:/opt/bitnami/mongodb/conf"
volumes:
mongodata:
I would like to stress this is a named volume, compared to the host volumes you are using. It is the best option for production and you need to be aware that docker will manage and store the files for you so you will not see the files in your project folder.
If you still want to use host volumes (so volumes that write to that location you specify in your project subfolder on the host machine) you need to apply a permission fix, here is an example for mariadb but it will work for mongo too
https://github.com/bitnami/bitnami-docker-mariadb/issues/136#issuecomment-354644226
In short, you need to know what is the user of the filesystem (in the example 1001 is the user id on my host machine for my logged in user) on your host and then chown that folder to this user so the user will be the same on the folder and your host system.
A full example:
version: "2"
services:
fix-mongodb-permissions:
image: 'bitnami/mongodb:latest'
user: root
command: chown -R 1001:1001 /bitnami
volumes:
- "./data:/bitnami"
mongodb:
image: 'bitnami/mongodb'
ports:
- "27017:27017"
volumes:
- ./data:/bitnami:rw
depends_on:
- fix-mongodb-permissions
I hope this helps