ibm / gameon-java-microservices-on-kubernetes Goto Github PK

Investigate why platform services need ip:port

• Try to use Istio
  or
• Try old images that were using amalgam8 sidecars

https://github.com/IBM/GameOn-Java-Microservices-on-Kubernetes#1-modify-the-yaml-files

Please script instead of manual.

@AnthonyAmanse

Bluemix Container service got its Kubernetes server version upgraded to v1.7.4 recently. After this upgrade, we started seeing issues with hostPath PersistentVolumes (PV) as reported in IBM/deploy-graph-db-container#3 (we had no such issues with the older v.1.5.x Kubernetes server version). Since this repo also uses hostPath PV, please test it out once and see if you need similar fix.

@Tomcli Please help get this Journey tested

if we switch it out for a string like xxxIPxxx then its easier to replace ... the following would be on linux ... I think the sed command is different on mac:

sed -i 's/xxxIPxxx/169......./' core/*.yaml

          - name: FRONT_END_PLAYER_URL
            value : https://169.47.241.213:30443/players/v1/accounts
          - name: FRONT_END_SUCCESS_CALLBACK
            value : https://169.47.241.213:30443/#/login/callback
          - name: FRONT_END_FAIL_CALLBACK
            value : https://169.47.241.213:30443/#/game
          - name: FRONT_END_AUTH_URL
value : https://169.47.241.213:30443/auth

becomes

          - name: FRONT_END_PLAYER_URL
            value : https://xxxIPxxx:30443/players/v1/accounts
          - name: FRONT_END_SUCCESS_CALLBACK
            value : https://xxxIPxxx:30443/#/login/callback
          - name: FRONT_END_FAIL_CALLBACK
            value : https://xxxIPxxx:30443/#/game
          - name: FRONT_END_AUTH_URL
            value : https://xxxIPxxx:30443/auth

The demo has been successfully deployed to the bluemix kubernetes， but can not access, error as the title

As per Tim Robinson - some issues

looking at the GameOn journey WIP… worked well using Deploy Toolchain button. But not so good with minikube on my Mac on 0.18.0 (latest). The problem I saw was that kubectl get nodes came back with a name instead of public IP of the cluster. All went good until trying to start the core services. Lots of

[ALERT] 124/015539 (10) : parsing [/etc/haproxy/haproxy-dev.cfg:97] : 'server room1' : invalid address: 'minikube' in 'minikube:30980'

[ALERT] 124/015539 (10) : parsing [/etc/haproxy/haproxy-dev.cfg:110] : 'server map1' : invalid address: 'minikube' in 'minikube:30947'

messages popping up. So I deleted it all and changed the replace IP script with the docker-machine ip of 192.168.99.100 and re-ran. Then it was happier. Things seem to start. However, the application seems to have problems working correctly. Not getting good information when moving to a room, unable to move back to the starting room. Were you getting better results with minikube?

some minor easy fixes I’d suggest. add an s (silent) option to these commands to just return the response codes:

curl -w "%{http_code}" ":31200/health" -o /dev/null

should be

curl -sw "%{http_code}" ":31200/health" -o /dev/null

I’d suggest to move to the teardown instructions the kubectl delete pod setup command. That way folks that use deploy to toolchain button will see it when doing the other cleanup.

final thing… drop the “s” from Dockers in the Reference item.

Travis are now recommending removing the sudo tag.

"If you currently specify sudo: false in your .travis.yml, we recommend removing that configuration"

Dear Colleague,

We are looking to find ways to help developers find security misconfigurations, i.e., Kubernetes manifest configurations that violate security best practices for Kubernetes manifests.

We have noticed an instance of absent resource limit in one of your Kubernetes manifests. Without resource limits Kubernetes installations could be susceptible to DDOS attacks (reff: https://arxiv.org/pdf/2006.15275.pdf).

Location:

Please fix this misconfiguration by adding requests and limits as shown here (https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). We would like to hear if you agree to fix this misconfiguration or have fixed the misconfiguration.

cc @AnthonyAmanse

I am trying to run the docker based microservices (without k8s). The proxy is exiting with code 1 as soon as I start things up using go-run up.

The output of docker logs proxy is as follows:

{"message":"Unable to find certificate /etc/cert/cert.pem"}
{"message":"Unable to find certificate /etc/cert/cert.pem"}
{"message":"Unable to find certificate /etc/cert/cert.pem"}

I guess because of this my go-run wait waits indefinitely.

Any hints will be highly appreciated.

Some of the images in this repo are unofficial, and sometimes not even automated builds so you can't click back to see the authenticity/makeup of the image. We should ensure that all images are either the official ones from docker ( or the software maker ) or part of an IBM docker repo with automated build etc turned on.

We should also pin them where possible to specific versions to help reduce the chance of upstream changes breaking the demo.

Here are some examples gathered from the k8s manifest files in the repo ... this is not all, just a few from a quick dig through:

keystore

This one is unpinned and is from a personal repo with no automated build or other information to show where it came from and if its authentic. It would be better if it came from an IBM docker repo and was pinned.

kafka

This one is also unpinned and from a personal repo, its a year old and is not automated build and has no details on where to find the origin dockerfile etc.

There does not appear to be an official image, however there are several that appear to have a good well known author/source:

• https://hub.docker.com/r/wurstmeister/kafka/
• https://hub.docker.com/r/tianon/kafka/
• https://hub.docker.com/r/spotify/kafka/

couchdb

This one is pinned and has autobuild on, but if possible would be better to use the official repo

https://hub.docker.com/r/klaemo/couchdb/