Can't connect to created database

[minhdanh]

Hello,

I'm deploying a PHP app. I've set up a MySQL service on a dedicated server and bound mysql service to that app. As I access the app site, it says that it can not connect to MySQL server. Here are the users of the database server:

And here're the default privileges on the created database (I created another db named 'testdbwp'):

After changing the host from '127.0.0.1' in both the 'user' and 'db' tables, I could get my app to work with the database. But is there any configuration or something that can make this happen automatically?

[andrewsmedina]

Hi @minhdanh can you share your mysql api environment variables (replacing sensitive data)?

[minhdanh]

Hi @andrewsmedina, how can I obtain those variables?

[fsouza]

@minhdanh are you using tsuru? can you share your tsuru.conf? More specific: the docker configuration, inside the tsuru.conf file.

[minhdanh]

Absolutely, I'm using tsuru. Here's my tsuru.conf file:

listen: "0.0.0.0:8080"

debug: true

host: http://example.com

# Uncomment the following lines to enable HTTPS on Tsuru. You will need the
# paths to the certificate and key files.
#
# use-tls: true
# tls-cert-file: /path/to/cert.pem
# tls-key-file: /path/to/key.pem

# Database configuration. Tsuru API needs a MongoDB server. By default, it will
# connect on localhost, in the default port, and use the database "tsuru".
# Uncomment and customize the lines below to change these values.
#
# database:
#   url: 127.0.0.1:27017
#   name: tsuru

# Git configuration. These settings refer to Gandalf, the git management tool
# used by Tsuru.
#
#   * unit-repo: it's the path where Tsuru will clone app code in units. This
#                value should not change after its initial definition.
#   * api-server: HTTP URL where Gandalf is accessible. Tsuru will use this URL
#                 to create users and repositories.
#   * rw-host: rw-host is the host string that will be used for reading and
#              writing in Git repositories. It will be used to build the SSH
#              URL for the git repository, and need to be accessible from the
#              internet.
#   * ro-host: ro-host is the host string that will be used for reading data
#              from Git repositories. It will be used to build the read-only
#              URL for the repository. This host need to be accessible from
#              units. You may use the private IP of the Gandalf host.
git:
  unit-repo: /home/git/bare-template
  api-server: http://127.0.0.1:8000
  rw-host: xxx.xxx.xxx.xxx
  ro-host: 172.17.42.1
# S3 Bucket support. When this flag is defined as true, Tsuru will create a S3
# bucket per application. Bucket creation depends on AWS settings (next
# section).
#
# bucket-support: false

# AWS configuration. Tsuru communicates with AWS to manage user credentials on
# IAM, load balancers on ELB and buckets on S3.
#
# Uncomment these settings if you want to create S3 buckets and manage ELB
# instances per app.
#
# aws:
#   access-key-id: access-id-here
#   secret-access-key: secret-very-secret
#   ec2:
#     endpoint: https://ec2.us-east-1.amazonaws.com
#   iam:
#     endpoint: https://iam.amazonaws.com/
#   s3:
#     region-name: us-west-1
#     endpoint: https://ec2.us-west-1.amazonaws.com
#     bucketEndpoint: https://s3-us-west-1.amazonaws.com
#     location-constraint: true
#     lowercase-bucket: true

# Authentication configuration.
#
#    * token-expire-days: this option controls the time (in days) for a token
#                         to expire.
#    * hash-cost: Tsuru uses bcrypt for password hashing, here you can control
#                 the cost of the hashing.
#    * user-registration: by default, users are not able to register themselves
#                         in Tsuru server (via the "user-create" command).
#                         Changing this options to true enables the user-create
#                         command.
#
# auth:
#   token-expire-days: 7
#   hash-cost: 10
#   user-registration: false
auth:
  user-registration: true

# Tsuru uses provisioners for creating units per app. There are two
# provisioners: Docker and Juju. In order to use the Juju provisioner, you need
# to uncomment the lines below and specify the settings you need.
#
# Juju configuration includes the following options:
#
#    * charms-path: the path to the local charms distribution. Tsuru's charms
#                   are hosted at github.com/globocom/charms.
#    * units-collection: the name of the database collection that Juju
#                        provisioner will use to store information about its
#                        units.
#    * use-elb: when defined as true, Juju provisioner will create ELB
#               instances when provisioning a new app.
#    * elb-endpoint: HTTP endpoint to the Elastic Load Balancing API.
#    * elb-collection: the name of the database collection the Juju provision
#                      will use to store information about ELB instances.
#    * elb-avail-zones: list of availability zones for the load balancer. This
#                       option is not necessary in VPC mode.
#    * elb-use-vpc: defines whether ELB instances should use VPC or ordinary
#                   EC2 networking. When in VPC mode, all load balancers will
#                   be created in internal mode. For more details, check AWS
#                   docs: https://aws.amazon.com/elasticloadbalancing.
#    * elb-vpc-subnets: list of subnets to use in VPC mode.
#    * elb-vpc-secgroups: list of security groups to use in VPC mode.
#
# provisioner: juju
# juju:
#   charms-path: /home/charms
#   units-collection: juju_units
#   use-elb: false
#   elb-endpoint: https://elasticloadbalancing.amazonaws.com
#   elb-collection: juju_load_balancers
#   elb-avail-zones:
#     - us-west-1a
#   elb-use-vpc: false
#   elb-vpc-subnets:
#     - network1
#     - network2
#   elb-vpc-secgroups:
#     - secgroup1
#     - secgroup2

# Below are settings for the Docker provisioner. Tsuru uses Docker in a
# clustered environment, so there are some settings related to the scheduling
# of containers in the cluster.
#
#    * servers: list of docker servers. Used in non-seggregated mode (see
#               seggregate for more details).
#    * collection: name of the database collection that Docker provisioner will
#                  use to store information about containers in the cluster.
#    * repository-namespace: the namespace to use in Docker images. For
#                            instance, an app named blog will have an image
#                            <namespace>/blog.
#    * router: the router to use.
#    * deploy-cmd: command to run every time user runs deploy. When using
#                  Tsuru's default images, just uncomment the line.
#    * ssh-agent-port: the port where Docker SSH agent runs on Docker nodes.
#    * seggregate: indicates whether tsuru should use a scheduler that
#                  seggregates containers among Docker nodes. When using this
#                  scheduler, each team will have a group of Docker nodes and
#                  Tsuru will spawn new containers for that team only on these
#                  nodes. This scheduler can be used to seggregate subnets per
#                  team.
#    * scheduler: configuration for the scheduler. In order to make the
#                  cluster run faster, it's recommended to use the Redis
#                  storage. It will store the relation between containers and
#                  nodes.
#    * run-cmd: command that will start the application. Also includes the port
#               that will be used for redirecting traffic. This is the port
#               that applications should bind.
#    * ssh: Tsuru will start the container with a SSH server. This section
#               contains options that describe which command will be used to
#               add the public key to containers, the public key path, the user
#               and the path to the SSH server (which is optional).

provisioner: docker
hipache:
  domain: example.com
docker:
  servers:
    - http://127.0.0.1:4243
  collection: docker_containers
  repository-namespace: tsuru
  router: hipache
  deploy-cmd: /var/lib/tsuru/deploy
  ssh-agent-port: 4545
  seggregate: true
  scheduler:
    redis-server: 127.0.0.1:6379
    redis-prefix: docker-cluster
  run-cmd:
    bin: /var/lib/tsuru/start
    port: "8888"
  ssh:
    add-key-cmd: /var/lib/tsuru/add-key
    public-key: /var/lib/tsuru/.ssh/id_rsa.pub
    user: ubuntu

# The address of the queue server (beanstalkd). By default, it's
# 127.0.0.1:11300. Uncomment and change for connecting in a different
# Beanstalkd instance.
#
# queue-server: "127.0.0.1:11300"

# The name of the admin team. When ommited, no team will be able to administrate Tsuru.
#
admin-team: admin

# Quota information. Tsuru supports two kind of quotas: number of units per app
# and number of apps per user.
#
# quota:
#   units-per-app: 2
#   apps-per-user: 2

[fsouza]

Can you try changing docker:servers to http://<public-ip-of-the-machine:4243, deploy your application again, unbind and bind it to the service and check whether it works?

As far as I remember, this is the address used when binding the application to the service instance.

[edouardkleinhans]

Hello,

Did you find a solution ?

[fsouza]

Hi @edouardkleinhans, which version of tsuru are you running? Is everything running in the same machine? Can you register the docker node using the public IP instead of localhost/127.0.0.1?

Sorry for the delay.

[edouardkleinhans]

Hi, I'm working with the latest version in deb packages. Everything is running on the same machine. Is it possible to pass the ip (or %) when creating user in database ?

Changing ip from 127.0.0.1 to 192.168.X.X change nothing.

[fsouza]

@edouardkleinhans strange, it should work. You need to change from 127.0.0.1 to 192.168.x.x, run another deployment, unbind and bind the application to the service instance. Can you try doing that?

[edouardkleinhans]

Hello, It don't work. Maybe I found where the issue is.

I think the "unit-host" variable is empty when you create a service. Wherre does this variable come from ?

[fsouza]

Well, it should not be empty, this variables comes from the containers collection in the database and represents the address of the host where the container is running.

Can you get into the database and show me which data you have in this collection? The name of the collection is configurable, you will find in the tsuru.conf file an entry named "collection", under the "docker" group. So you can run this query:

db.<collection-name>.find({id: /<container id>/)

Thanks, and sorry for these failures!

[edouardkleinhans]

{ "_id" : ObjectId("53cfc7757bf9d42a6273d713"), "id" : "93e3cd447cdfd0689bda902db81e4826bd09ed50a55cb4b65f25f2ed163bc655", "appname" : "mysqlapi", "type" : "python", "ip" : "172.17.0.24", "hostaddr" : "192.168.1.130", "hostport" : "49166", "status" : "started", "version" : "", "image" : "tsuru/mysqlapi", "name" : "0238ded0ba1e1b37a7b6" }

[fsouza]

So, do you have an entry in the api database with this host?

select user, host from mysql.user where host = '192.168.1.130';

[edouardkleinhans]

No,

it always create en entry as 127.0.0.1 when i do the binding

[fsouza]

That's surprising. What's the version of your tsuru server?

% tsr version

[edouardkleinhans]

tsr version 0.5.2.

2014-07-30 16:03 GMT+02:00 Francisco Souza notifications@github.com:

That's surprising. What's the version of your tsuru server?

% tsr version

— Reply to this email directly or view it on GitHub https://github.com/tsuru/mysqlapi/issues/33#issuecomment-50618311.

[edouardkleinhans]

Hello,

It works now with the last update. Thanks a lot for your help.

Regards Edouard

[fsouza]

That's great news! :)

Please let us know if you need any further help.