As the title, is there any guide to deploy keycloak to cloud foundry?
Seems like cloudfoundry is only friendly to spring boot applications.
In my experience the easiest solution is to wrap Keycloak in a Spring-Boot application (together with the required JBoss parts) and deploy that. This allows you to create a single jar and push that to Cloud Foundry with the standard Java build pack.
This is exactly what someone has done in this Github project. The project injects a basic configuration for Keycloak with the default H2 database. All you need to do is clone the project, run mvn package and push the resulting jar to CF.
Keycloak Single Instance on CF
To deploy single instance try to cf push the docker image using manifest.yml like this (Postgres DB example):
---
applications:
- name: sso
docker:
image: jboss/keycloak
instances: 1
memory: 2G
disk_quota: 2G
env:
PROXY_ADDRESS_FORWARDING: true
DB_VENDOR: postgres
DB_ADDR: 192.168.1.23
DB_PORT: 5432
DB_DATABASE: keycloakdb
DB_USER: keycloak
DB_PASSWORD: a-lot-of-asterisks
You can do it also with the following commands without a manifest file:
$ cf push sso --docker-image jboss/keycloak -i 1 -m 2G -k 2G --no-start
$ cf set-env sso PROXY_ADDRESS_FORWARDING true
$ cf set-env sso DB_VENDOR: postgres
$ cf set-env sso DB_ADDR 192.168.1.23
$ cf set-env sso DB_PORT 5432
$ cf set-env sso DB_DATABASE keycloakdb
$ cf set-env sso DB_USER keycloak
$ cf set-env sso DB_PASSWORD a-lot-of-asterisks
$ cf env sso
$ cf start sso
$ cf logs sso --recent
Keycloak HA Cluster ona CF
Please look at: Keycloak standalone cluster on Cloud Foundry
References
https://hub.docker.com/r/jboss/keycloak/
https://cli.cloudfoundry.org/en-US/cf/push.html
https://docs.cloudfoundry.org/adminguide/docker.html#public
Do you consider using Cloud Foundry's UAA?
CF UAA is the central identity management service for both users and applications, that supports: federated login, LDAP, SAML, SSO and multifactor authentication.
Related
I'm trying to deploy docker compose to amazon ECS.
I have created this docker compose file:
services:
consul-server:
container_name: consul-server
hostname: consul-server
image: consul:1.12.2
command: agent -server -ui -node=server1 -bootstrap-expect=1 -client=0.0.0.0
ports:
- 8400:8400
- 8500:8500
- 8600:8600/udp
networks:
- xp_network
infra-service:
image: infra-service-docker-img:latest
build: .
container_name: infra-service
hostname: infra-service
ports:
- 5011:5011
networks:
- xp_network
networks:
dxp_network:
name: xp-vpc
I create an ECS context to target Amazon ECS using the following commands:
docker context create ecs ecscontext
I have AWS credentials set up in the local environment for authenticating with the ECS platform.(I did aws configure and add the keys)
and then I use an existing AWS profile. After I checked i created the new context (docker context ls) I ensured that i was using my context.
Run --> docker compose up
When I a do docker-compose up -d I can see that Container infra-service Started and Container consul-server Started.
When I check the state of the services I can not see any difference on the PORTS. No connection to aws and no resources created there also :S
enter image description here
basically I did:
$ aws configure
--> keys
--> region
$ docker compose build
$ docker context create ecs ecscontext
--> An existing AWS profile
$ docker context use ecscontext
$ docker compose up
$ docker compose ps
PLEASE!!!Anyone can tell me what I'm doing wrong? Do you think that it's something related to the credentials set up?
I have testng project with selenium for integration testing of frontend app in vuejs and springboot backend. So in order to run tests I need first to bring up all dependent projects:
springboot and mongodb
vuejs frrontend app
Each project is in its own repo.
So I have created docker images of springboot and frontend app and will put it up in gitlab container registry.
Then in the testeng project plan to use docker-compose in .gitlab-ci.yml. Here is docker-compose.yml for testng project:
version: '3.7'
services:
frontendapp:
image: demo.app-frontend-selenium
container_name: frontend-app-selenium
depends_on:
- demoapi
ports:
- 8080:80
demoapi:
image: demo.app-backend-selenium
container_name: demo-api-selenium
depends_on:
- mongodb
environment:
- SPRING_PROFILES_ACTIVE=prod
- SCOUNT_API_ENDPOINTS_WEB_CORS_OPTIONS_ALLOWEDORIGINS=*
- SPRING_DATA_MONGODB_HOST=mongodb
- SPRING_DATA_MONGODB_DATABASE=demo-api-selenium
- KEYCLOAK_AUTH-SERVER-URL=https://my-keycloak-url/auth
ports:
- 8082:80
mongodb:
image: mongo:4-bionic
container_name: mongodb-selenium
environment:
MONGO_INITDB_DATABASE: demo-api-selenium
ports:
- 27017:27017
volumes:
- ./mongo-init.js:/docker-entrypoint-initdb.d/mongo-init.js:ro
After running docker-compose in gitlab-ci.yml what will be url of frontend app in order to execute tests?
When I do it locally I am using following urls for testing:
frontend app: http://localhost:8080
api: http://localhost:8082
But in case when running on gitlab ci what will be url to access frontend and api?
TL;DR instead of using localhost you need to use the hostname of your docker daemon (docker:dind) service. If you setup docker-in-docker for your GitLab job per usual setup, this is most likely docker.
So the urls you need to use according to your compose file are:
frontend app: http://docker:8080
api: http://docker:8082
my_job:
services:
- name: docker:dind
alias: docker # this is the hostname of the daemon
variables:
DOCKER_TLS_CERTDIR: ""
DOCKER_HOST: "tcp://docker:2375"
image: docker:stable
script:
- docker run -d -p 8000:80 strm/helloworld-http
- apk update && apk add curl # install curl and let server start
- curl http://docker:8000 # use the daemon to reach your containers
For a full explanation of this, read on.
Docker port mapping in Gitlab CI vs locally
How it works locally
Normally, when you use docker-compose locally on your system, you are typically running the docker daemon on your localhost (e.g. using docker desktop).
When you provide a port mapping like 8080:80 it means to publish port 8080 on the daemon host bound to port 80 in the container. When running locally, that means you can reach the container via localhost.
In GitLab
However, when you're running docker-in-docker on GitLab CI the important difference in this environment is that the docker daemon is remote. So, when you expose ports through the docker API, the ports are exposed on the docker daemon host not locally in your job container.
Hence, you must use the hostname of the docker daemon, not localhost, to reach your started containers.
Alternative solutions
An alternative to this would be to conduct your testing inside the same docker network that you create with your compose stack. That way, your testing is agnostic of where the docker environment lives and can, for example, leverage the service aliases in your compose file (like frontendapp, demoapi, etc) instead of relying on published ports.
For example, you may choose add a test container to your compose stack. Some testing libraries like Testcontainers can help set this up, too.
I've set up Hasura on a DigitalOcean droplet using the instructions here - https://docs.hasura.io/1.0/graphql/manual/guides/deployment/digital-ocean-one-click.html -
How can I connect to the Postgres database? Preferably using something like DBeaver - with host, database, user, password.
I guess the Postgres is running inside a Docker container, but how do you expose it to the outside world?
The docker-compose.yaml used on the Digital Ocean Marketplace does not expose the Postgres database on the host machine.
You can find the file at /etc/hasura/docker-compose.yaml. If your database management tool supports running as a docker container, I recommend adding it's relevant configuration to the docker-compose.yaml and exposing that application to the ouside like how graphql-engine is exposed via Caddy (config in /etc/hasura/Caddyfile.
But if you'd like to connect to postgres from within the machine, add a port mapping to the docker-compose file:
postgres:
image: postgres:10.5
restart: always
volumes:
- db_data:/var/lib/postgresql/data
ports:
- "127.0.0.1:5432:5432"
Now, Postgres will be available at postgres://postgres:#127.0.0.1:5432/postgres
Do set a password if you're exposing it on the host machine.
I'm a new Ambassador user here. I have walked thru the tutorial, in an effort to understand how use ambassador gateway. I am attempting to run this locally via Docker Compose until it's ready for deployment to K8s in production.
My use case is that all http traffic comes in on port 80, and then directed to the appropriate service. Is it considered best practice to have a docker-compose.yaml file in the working directory that refers to services in the /config directory? I ask because this doesn't appear to actually pickup my files (the postgres startup doesn't show in console). And when I run "docker ps" I only show:
CONTAINER ID IMAGE PORTS NAMES
8bc8393ac04c 05a916199684 k8s_statsd_ambassador-8564bfb874-q97l9_default_e775d686-a93c-11e8-9caa-025000000001_0
1c00f2341caf d7cf7cf837f9 k8s_ambassador_ambassador-8564bfb874-q97l9_default_e775d686-a93c-11e8-9caa-025000000001_0
fe20c4819514 05a916199684 k8s_statsd_ambassador-8564bfb874-xzvkl_default_e775ffe6-a93c-11e8-9caa-025000000001_0
ba6415b028ba d7cf7cf837f9 k8s_ambassador_ambassador-8564bfb874-xzvkl_default_e775ffe6-a93c-11e8-9caa-025000000001_0
9df07dc5083d 05a916199684 k8s_statsd_ambassador-8564bfb874-w5vsq_default_e773ed53-a93c-11e8-9caa-025000000001_0
682e1f9902a0 d7cf7cf837f9 k8s_ambassador_ambassador-8564bfb874-w5vsq_default_e773ed53-a93c-11e8-9caa-025000000001_0
bb6d2f749491 quay.io/datawire/ambassador:0.40.2 0.0.0.0:80->80/tcp apigateway_ambassador_1
I have a docker-compose.yaml:
version: '3.1'
# Define the services/containers to be run
services:
ambassador:
image: quay.io/datawire/ambassador:0.40.2
ports:
- 80:80
volumes:
# mount a volume where we can inject configuration files
- ./config:/ambassador/config
postgres:
image: my-postgresql
ports:
- '5432:5432'
and in /config/mapping-postgres.yaml:
---
apiVersion: ambassador/v0
kind: Mapping
name: postgres_mapping
rewrite: ""
service: postgres:5432
volumes:
- ../my-postgres:/docker-entrypoint-initdb.d
environment:
- POSTGRES_MULTIPLE_DATABASES=db1, db2, db3
- POSTGRES_USER=<>
- POSTGRES_PASSWORD=<>
volumes and environment are not valid configs for Ambassador Mappings. Ambassador lets you proxy to postgres but the authentication has to be handled by your application.
Having said that, it looks like your Postgres container is not starting. (Perhaps because it needs an initial config). You can check for errors with:
$ docker ps -a | grep postgres
$ docker logs <container-id-from-previous-step>
You can also check a postgres docker compose example here.
Is it considered best practice to have a docker-compose.yaml file in the working directory that refers to services in the /config directory?
It's pretty standard, but you can use any directory you like for this.
In these days, I am trying to deploy my Spring Boot OAuth2 project. It has 3 different modules.(Authentication Server, Resource Server and Front-end)
Authentication and Resource servers have own *.yml file for configurations such as mongodb name-port, server profile-ip etc.
What I am trying to do exactly? I want to deploy spring boot application on docker but i dont want to put my database(mongodb) on docker as a container.
I am not sure this structure is possible or not ?
Because When i run my mongodb on my local(localhost:27017) after that try to deploy spring boot application on local docker as a container, i am getting Timeout exception for MongoDB. The application couldnt connect to external mongoDB(non docker container).
What should I do? Should I run mongodb on docker? I tried it also, Mongo runs successfully but still spring container couldnt run and connect to mongo.
I tried to run another spring boot app without mongodb, it is working successfully and i made request from browser by ip&port, i got response from application as i expected.
*** MONGO URL ****
mongodb://127.0.0.1:27017/db-localhost
**** Authentication server .yml file ****
server:
port: 9080
contextPath: /auth-service
tomcat:
access_log_enabled: true
basedir: target/tomcat
security:
basic:
enabled: false
spring:
profiles:
active: development
thymeleaf:
cache: false
mongo:
db:
server: 127.0.0.1
port: 27017
logging:
level:
org.springframework.security: DEBUG
---
spring:
profiles: development
data:
mongodb:
database: db-localhost
---
spring:
profiles: production
data:
mongodb:
database: db-prod
---
***** DOCKER FILE *******
FROM java:8
VOLUME /tmp
ADD auth-server-1.0-SNAPSHOT.jar app.jar
EXPOSE 9080
RUN bash -c 'touch /app.jar'
ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]
**** DOCKER COMMAND *******
docker run -it -P --name authserver authserver
The issue with your configuration is referencing the mongodb from inside of the authservice on 127.0.0.1 which is the loopback adapter inside of the authservice container. So you tell your spring application that mongodb is running in the same container as the authservice spring application, which is not the case.
Either you are running your database as an own container (which requires to handle the data volumes correctly) and referencing it using the container name as hostname (via link) or you need to reference the externally running mongodb instance with the correct address. This would be the ip address of the machine running the docker daemon (I assume for your local environment something like 192.168.0.xxx).
Question: What should I do?
At least for developing purposes I would recommend to also use docker for your mongodb instance. I had a similar setup with RabbitMQ in addition and it solved a lot of problems when I used docker for those as well. Using docker-compose to set everything up makes it even easier. Later you can still specify which mongodb instance you want to use through your spring properties.
Problem: I tried it also, Mongo runs successfully but still spring container couldnt run and connect to mongo
The problem is probably because you have not set up any networks or hostnames for you services. Your spring application can not resolve the hostname of your mongo server, since you specified 127.0.0.1 for your mongodb server in your properties.
I would recommend using docker for your mongodb and use a docker-compose.yml file like this to set everything up:
version: '3.7'
services:
resource-server:
image: demo/resource-server:latest
container_name: resource-server
depends_on:
- mongodb-example
networks:
- your-network
ports:
- 8080:8080
auth-server:
image: demo/auth-server:latest
container_name: auth-server
depends_on:
- mongodb-example
networks:
- your-network
ports:
- 8081:8080
mongodb-example:
image: mongo:latest
container_name: mongo-example
hostname: mongo-example
networks:
- your-network
ports:
- 27017:27017
networks:
your-network:
name: network-name
Of course you then need to adapt your property file or specify environment variables through your docker-compose.yml file.