Add option to turn off endpoint SSL/TLS certificate verification

[brotandgames]

Add option to turn off endpoint SSL/TLS certificate verification

[brotandgames]

@Mahdi-Hosseini Did any of the solutions (one, two) work for you?

[tareksamni]

This should be an easy to implement feature. I will open a PR today with the changes.

[brotandgames]

@Mahdi-Hosseini Suppose you are using Docker to deploy ciao. Why don't you add your needed certs by mounting them in the container?

If the certificate store on the host is compatible with the guest (Docker container based on alpine Docker image), you can just mount it:

docker run --name ciao \
  -p 8090:3000 \
  -v /etc/ssl/certs:/etc/ssl/certs:ro \
  brotandgames/ciao

Would this solution work for you?

[brotandgames]

@Mahdi-Hosseini If the host is not compatible with the guest you would have to mount the cert(s) into /usr/local/share/ca-certificates and run update-ca-certificates before ./start.sh like

docker run --name ciao \
  -p 8090:3000 \
  -v /path/to/certs:/usr/local/share/ca-certificates \
  brotandgames/ciao \
  update-ca-certificates && ./start.sh

[tareksamni]

@brotandgames I think we should change:

CMD ["./start.sh"]

in the docker file to:

ENTRYPOINT ["./start.sh"]

and change start.sh to not run rails s.

Then he could run:

docker run --name ciao \
  -p 8090:3000 \
  -v /path/to/certs:/usr/local/share/ca-certificates \
  brotandgames/ciao \
  update-ca-certificates

Which will run the passed CMD update-ca-certificates and the entrypoint as well start.sh

[tareksamni]

@brotandgames #29 this is a simple change and provides more flexibility to target this issue.

[brotandgames]

@tareksamni
From StackOverflow:

ENTRYPOINT should be defined when using the container as an executable

or

The ENTRYPOINT specifies a command that will always be executed when the container starts. The CMD specifies arguments that will be fed to the ENTRYPOINT.

or

CMD should be used as a way of defining default arguments for an ENTRYPOINT command or for executing an ad-hoc command in a container.

Would leave it as it is and what's wrong with just simply overriding the CMD?

[tareksamni]

I use ENTRYPOINT as an "entry point" to bootstrap the environment for the application to run. For ex. to rake db:migrate or run any other dependencies. and then execute the CMD afterwords. This is a good practice and most of the docker public images are doing the same. It's not delivering or preventing an immediate value in our project now but it's a good practice to isolate the actual command "rails s" and any other work to happen before "bootstrap".

[brotandgames]

This is a good practice and most of the docker public images are doing the same.

Don't agree. Here you can find a nice explanation.

[tareksamni]

This explanation is exactly what I understand about CMD and ENTRYPOINT and that's why I was recommending using the ENTRYPOINT. It's offtopic anyway :)

Just examples from the open-source community:

https://github.com/docker-library/postgres/blob/master/Dockerfile-alpine.template
https://github.com/docker-library/redis/blob/master/5.0/Dockerfile
https://github.com/docker-library/rabbitmq/blob/master/Dockerfile-alpine.template
https://github.com/docker-library/mongo/blob/master/4.1/Dockerfile

[brotandgames]

In your examples the ENTRYPOINT is used in another way than in the explanation above.
As you stated: it's off-topic anyway ;)

Want to keep the start.sh as it is and if someone needs to overwrite the CMD it's simple as shown here.

[mike-hosseini]

Yes, thank you for providing those tips!