add docker based on restcomm-connect with cassandra at localhost

[c5c86a]

Tested with travis

[deruelle]

Thanks @nicosmaris !

@leftyb can you review from a docker best practices standpoint ? @vetss @nhanth87 can you review from a functional standpoint ?

[leftyb]

Hi @nicosmaris,

The container looks Ok, from my first review. I would like to ask you to provide some configuration examples for basic RUN of the container. I mean at the env_files directory I can see typical RC configuration options files. Is it actually possible to use those files to configure RC? (I can see that there is this option at the docker scripts.) I am asking because at the ReadME file I can see only the very basic run command. Should as well everything run with that basic command? docker run --name smsc --net=host -p 0.0.0.0:8080:8080 -d restcomm/smsc

Regards.

[c5c86a]

Hi @leftyb ,

Indeed it needs some cleanup as the folder env_files was copied from restcomm-docker. How is it being used in restcomm-docker? The following file starts that docker and it doesn't seam to use the env_files folder, right? https://github.com/RestComm/Restcomm-Docker/blob/master/scripts/restcomm_service.sh

For SMSC, the commands are two: docker run --name db --net=host -p 127.0.0.1:9042:9042 -p 127.0.0.1:9160:9160 -d cassandra docker run --name smsc --net=host -p 0.0.0.0:8080:8080 -d restcomm/smsc

The first one starts a cassandra on localhost and the second one starts an smsc which calls localhost at 9042

For a multiple VM setup, the java of smsc should look for cassandra ip and fallback to localhost if no such env var is provided. Until then a single VM setup might be fine for an initial docker to play with.

Generally, the bind address of SMSC, the port, the usage of 'default' server or simulator, the cassandra ip, the log path and the loglevel should be on environment variables.

[leftyb]

Hi @nicosmaris You can find some explanation here on how to run normal docker container: http://documentation.telestax.com/connect/configuration/docker/Restcomm%20-%20Docker%20Quick%20Start%20Guide.html#install-and-run-restcomm-docker

I dont get your comment there: "Generally, the bind address of SMSC, the port, the usage of 'default' server or simulator, the cassandra ip, the log path and the loglevel should be on environment variables."

I see that you use the restcomm_conf.sh, restcomm_sslconf.sh,restcomm_support_load_balancer.sh Are those actually used?

[c5c86a]

No they don't, I copied them so that we discuss about them :)

Should I delete them and edit only the restcomm_env_locally.sh ?

[c5c86a]

@leftyb please ignore my comment "Generally...", I just saw the README of phusion and I understood a bit all the environment variables of all those bash scripts.

I prefer having Convention over Configuration so I have put also some default values which are currently the same but changes on the new (sample) env_file have been tested at 8c4b728.

As regards logging, the lines 73 and 74 of Dockerfile put the jboss logs in a place in which you can see them with 'docker logs', is this the preferred way?

[c5c86a]

@leftyb after removing the unused files, all remaining scripts are used and the provisioning of logs works fine.

There are researchers who want to use SMSC docker, do you expect to have one at docker hub this month? If you want, I can assist you in doing a docker push from travis. I haven't done it yet as the group of dockerhub should be restcomm and not mine.

[leftyb]

@nicosmaris of course I will review tomorrow again and will update.

Thanks.

[leftyb]

Hi @nicosmaris,

After discussing today with the DevOps team, We will need to add the possibility to use as well cassandra from an external service, not only running in localhost. Do you think that you can add this option as well? As for production almost never, DB will be running locally in the same machine as the smsc gateway service.

Thank you.

[deruelle]

@leftyb if the current code is good. Let's merge and create a separate issue for external cassandra

[c5c86a]

@leftyb I can try. I have a provisioner of VMs at the following repo but I am stuck on a weird error:

https://github.com/nicosmaris/vm/blob/master/deploy/smsc.sh#L5

apt is locked when I get the VM from the cloud provider and I cannot 'apt-get install' so I either 'sleep' for an amount of time or use 'aptdcon'. If you have even used aptdcon or you have any other idea, let me know.

[leftyb]

@nicosmaris What I mean is to be able to configure IP and port for Cassandra DB. Something I see that is done here: echo "CASSANDRA_IP: ${CASSANDRA_IP:="127.0.0.1"}". But I think there is a problem there. You dont actually set the CASSANDRA_IP variable with 127.0.0.1 if not set, you are just printing it. Or I am mistaken?

At the file restcomm_setenv.sh can you please delete all the non used variables. I get that no need for all those variables to be used at the RUN command line.

Related your last comment, I dont really understand why you use travis, and what is the problem you are facing. Can you please elaborate a bit more please?

Regrards.

[c5c86a]

The echo command has an optional substitution in case the variable is not defined. For example:

nmaris@nmaris:~$` echo $B

nmaris@nmaris:~$ B='10.11.12.13'
nmaris@nmaris:~$ echo "B: ${B:="127.0.0.1"}"
B: 10.11.12.13
nmaris@nmaris:~$ echo $C

nmaris@nmaris:~$ echo "C: ${C:="127.0.0.1"}"
C: 127.0.0.1

I would prefer to continue the discussion of the multiple VM setup in a new thread as it is needs more than one week effort. I see that you have forked vm repo, but note that you'll need a vultr token and to do so you need a vultr account (about 1 cent of dollar per commit and a bank account), the travis ruby gem and the command described at the link below:

https://docs.travis-ci.com/user/environment-variables/#Encrypting-environment-variables

Also the java has to change as it has hardcoded the value 127.0.0.1 as cassandra ip.

[leftyb]

I see @nicosmaris you are right, on the echo thanks for clearing out. Can you please cleanup the restcomm_setenv.sh so we can move forward with the PR.

Regards

[leftyb]

@nicosmaris can you please as well remove all unused env files from the env_files directory. Same fortcpdump_crontab` .

It seems as well that the dockerfile needs some cleanup as well.

[leftyb]

@nicosmaris what are this lines used for : RUN ln -sf /dev/stdout /opt/Restcomm-SMSC/version RUN ln -sf /dev/stdout /opt/Restcomm-SMSC/jboss-5.1.0.GA/server/simulator/log/server.log RUN ln -sf /dev/stdout /opt/Restcomm-SMSC/jboss-5.1.0.GA/server/simulator/log/boot.log

Can you please update the command at the README file with the possibility to access the logs of the container from the host?

Thank you.

[c5c86a]

/dev/stdout is the stream of 'docker logs'.

As regards the file ca-startcom.der, I assume that we should keep it and add support of SSL in another ticket. If we'll need a new one anyway, I can delete it.

[leftyb]

Hi @nicosmaris I am not sure that you need to redirect the application logs in order to be able to be accessible from the docker logs command. I would say that this is something that is done under the hood by docker automatically. I tested as well and there is not need for this redirection. Can you please test as well.

Finally, it seems that the directory /opt/Restcomm-SMSC/jboss-5.1.0.GA/server/simulator/log is automatically created from the smsc application no need to created at the docker file. It is better to remove those lines from docker file if not needed because they create additional layers and make the container bigger. Please confirm as well, but from my tests it seems that no needed.

Regards.

[leftyb]

@nicosmaris I see that you are doing a lot of changes. I think that it is not necessary. It was OK as it was before. At my earlier comment just said (and tested it) that you don't need to add the ln commands, as well you dont need to add p ${INSTALL_DIR}/jboss-5.1.0.GA/server/simulator/log as it is created automatically from Jboss.

Regards.

[c5c86a]

Indeed Jboss creates the files but not the folder. Also in order for the command 'docker logs' to work we need to link them.

As the following build states No such file or directory: '/opt/Restcomm-SMSC/cassandra/cassandra.cql' and the test with curl passed again, we need to find another way to test the functionality.

https://travis-ci.org/nicosmaris/smscgateway-docker/builds/190954292

If it is less readable now, I can revert my last commit.

[leftyb]

Sorry I dont get your point : /opt/Restcomm-SMSC/cassandra/cassandra.cql What is this file about. Needs to be created, or it is supposed to exist?

About the logs directory and the docker logs command, I will retest. I am pretty sure that not needed. Are you using the command like that? docker logs -f CONTAINER_NAME?

Regards

[c5c86a]

Why retesting, when you can read the output? That's the point of using travis. Anyway.

Based on the following comment and the guide, having cassandra and creating the keyspace are preconditions for SMSC. The cql file creates the keyspace and it is part of the artifact.

https://github.com/RestComm/smscgateway/issues/53#issuecomment-269602214

http://docs.telestax.com/smsc-quick-start-user-guide/

As regards having a sanity check I can check in python for zero SM_STATUS at response of /SMS/Messages.json , is there any other prefered sanity check that can be done in a script? The curl returns HTTP 200 even in erroneous cases.

[leftyb]

I dont see that you are running the docker logs command at your builds.

Regarding cassandra.cql file, I am asking if the problem is that the script can not create the file, or it is necessary that the file needs to exist from before? (Add it at the docker file maybe).

[c5c86a]

I call 'docker logs' indirectly:

https://github.com/nicosmaris/smscgateway-docker/blob/master/.travis.yml#L20 https://github.com/nicosmaris/smscgateway-docker/blob/master/provisioner/docker_do.sh#L308 https://github.com/nicosmaris/smscgateway-docker/blob/master/provisioner/docker_do.sh#L91

docker_do.sh is copied from: https://github.com/RestComm/Restcomm-Docker/blob/master/scripts/docker_do.sh

The issue with cassandra.cql is fixed since 6b3a5f5. What is pending now is the sanity check.

[leftyb]

But this script is sending the logs to specific file. Is the entire path correct? This is more like RC container specific script. Most probably you need to modify. Can you run the docker logs directly and remove the ln and the mkdir you will see that it works properly.

Sorry but I am loosing you on the sanity check. Can you check the actual system JSON response instead of the correct curl 200 response?

[c5c86a]

For the sanity check, yes, that's my plan as stated above...

[vetss]

Hello @nicosmaris

thanks for your efforts.

Which checking can you make for sanity check? Is it possible of checking of server log content? The problem is that SMMSC GW is rather complicated and generally demands of checking of several things. For example HTTP connector may accept messages even if other modul will not be started. We can make checking of absense of "Exception" strings and existing of a message that "jboss is started".

[c5c86a]

@deruelle my plan for the first two months of 2017 is to take issues that see the restcomm components as black boxes like dockers and clients. After becoming familiar with the terms and the APIs I might do some whitebox testing in java.

@vetss manually I do see "jboss is started". Now to do an automated sanity check of the docker I don't plan to do assertions on logs. Currently I check an API call that I am not sure whether it is an API of SMSC and Connect or only an API of Connect.

I check that the response of getting list of messages returns an authorized attempt (exit status zero) and not a connection refused (exit status 1)

http://documentation.telestax.com/connect/api/sms-api.html#example-get-response https://travis-ci.org/nicosmaris/smscgateway-docker#L978

However, if by mistake I don't put any keyspace at cassandra, I still get exit status zero, is it expected?

Should I keep the same check and replace the API call with the following one?

http://documentation.telestax.com/core/smsc/SMSC_Gateway_Admin_Guide.html#_http_interface_description_get_message_status

[vetss]

Hello @nicosmaris

what is your target for "sanity check"? I see two possible targets: 1) checking if SMSC GW has started or not 2) checking if SMSC GW has started but had some problems at starting time that will prevent of its proper work

Sending of a message to HTTP connector and checking of its state "Get message status"may help if we have some configured destination (SMPP, SS7 or SIP) for message delivering to obtain a state if a message has delivered or not. I am not very sure that we can guarantee it. And also pay attention that it will work in case of some errors.

Unfortunately we do not provide a clear state of SMSC GW to check by a remote request, may be we need to think of it. As for now the most reliable solution is for checking of server log if it contain "jboss is started" for target 1 and absense of Exceptions for target 2.

Sending of HTTP request (that do you) may help us in checking if HTTP connectior is started or not.

[deruelle]

@nicosmaris @vetss @leftyb I think we should aim for a first version of the docker image that's simple and easily configurable like Restcomm Connect for the first pull request.

Things like sanity check (that we don't even have with Restcomm Connect docker image right now) and more advanced can be done in future pull requests, IMO.

[c5c86a]

thanks for the merge @leftyb

@vetss the successful startup message that you mentioned is at the following line:

https://travis-ci.org/nicosmaris/smscgateway-docker/builds/191270068#L4035

[vetss]

1) "JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] Started in 57s:489ms" - is a message that confirms that a starting processes are finished.

2) but SMSC GW has not started successfully. Records that says for it: a) "Not all SBB are running now: ServicesDownList=[smscTxSmppServerServiceState, smscRxSmppServerServiceState, smscTxSipServerServiceState, smscRxSipServerServiceState, smscTxHttpServerServiceState, moServiceState, homeRoutingServiceState, mtServiceState, alertServiceState, chargingServiceState, ]"

b) Failed to build ManagedDeployment for: AbstractKernelDeployment@23fcb72b{name=file:/opt/Restcomm-SMSC/jboss-5.1.0.GA/server/simulator/conf/bootstrap/logging.xml installed=true beanFactories=[AbstractBeanMetaData@245d7a82{name=LogBridgeHandler bean=org.jboss.logbridge.LogBridgeHandler properties= constructor=null autowireCandidate=true}]} org.jboss.deployers.spi.DeploymentException: Error deploying: file:/opt/Restcomm-SMSC/jboss-5.1.0.GA/server/simulator/conf/bootstrap/logging.xml

[vetss]

Althow "DeploymentException" is at DEBUG level, it may be not an error... But it is not clear for me why we do not have "ServicesDownList" (services that are not started)

[c5c86a]

logging.xml is not modified. It is the file of the artifact and it has the following content:

<deployment>
<bean name="LogBridgeHandler" class="org.jboss.logbridge.LogBridgeHandler"/>
</deployment>

@vetss do you want to make the startup of the SMSC GW a new issue to avoid polluting this thread? How can I help?

[vetss]

@nicosmaris

do you think that SMSC GW in docker is started properly ? as for your last provided log I do not see that... Or in other cases it starts properly. If not we need to find the reason / fix it before we can use a docker image.

[c5c86a]

@vetss no it doesn't start properly. are the tests of the latest artifact passing?

[c5c86a]

I synced my repo with yours again and downloaded the latest artifact 7.3.114.

At boot.log indeed the deploymentException can be ignored.

https://developer.jboss.org/wiki/ClassLoaderHasNotBeenSetExceptionInBootlog

At server.log the error below appears in all of the following lines.

ERROR [org.hibernate.ejb.Ejb3Configuration] (SLEE-InternalDeployer-thread-1) Container is providing a null PersistenceUnitRootUrl: discovery impossible

https://travis-ci.org/nicosmaris/smscgateway-docker/builds/191730838#L1274 https://travis-ci.org/nicosmaris/smscgateway-docker/builds/191730838#L1333 https://travis-ci.org/nicosmaris/smscgateway-docker/builds/191730838#L1392 https://travis-ci.org/nicosmaris/smscgateway-docker/builds/191730838#L1446

And this error might be ignored too.

https://cwiki.apache.org/confluence/display/GMOxSAMPLES/Running+JBoss+Seam+2.0.0.GA+on+Geronimo+2.1.1

However we need logs for the ServicesDownList. Is there any other log file that might provide info about the ServicesDownList?

[vetss]

Hello @nicosmaris

https://travis-ci.org/nicosmaris/smscgateway-docker/builds/191730838#L1274 - we can ignore it ARAIR

Do we have a GUI access to the server (HTTP requests to port 8080) ? If yes we can run http://:8080/slee-management-console/ and check "Resources" and "Services" TABs, they must contains running RAs and SBBs list. If no SBB in "services" then no success in starting process.

I am also thinking that I can see too many DEBUG messages in logs, may be we can fix it somehow up to INFO level. We use for jboss logging configs /server/default/conf/jboss-log4j.xml . Is this not checnged as compared with a SMSC GW release ? May it be that other logging system is used unstead of instead of log4j that we usually use ?

[c5c86a]

Locally, the GUI shows JAIN SLEE running and several resources but no services and no alarm.

No file of the artifact has been altered and raising the JVM memory with JAVA_OPTS gives the same result.

[vetss]

Locally, the GUI shows JAIN SLEE running and several resources but no services and no alarm.

ok, let's do some reseach next week why SMSC GW does not run properly..

[deruelle]

@nicosmaris we investigated with @vetss and it was an issue on the snapshot on cloudbees, the latest snapshot would be working now but I nonetheless moved to the latest github stable release. I just tested the latest docker hub build locally and it works now

[c5c86a]

@deruelle currently when do you push at docker hub? On demand through jenkins or by registering the repository to docker hub?

In case the issue appears in docker and not in a local installation without docker, we'll have to check the parameters of run.sh (called at scripts/restcomm_smsc_service.sh), exposed ports of Dockerfile and parameters of 'docker run'.

https://github.com/jboss-dockerfiles/wildfly/issues/6

To a make an automated test, I will check in another pull request the HTTP connector through python as checking the exit status of a curl is not valid.

[deruelle]

@nicosmaris right now every commit to master triggers a new docker build.

Sounds good. I added xmlstartlet to the docker image as well to configure the SMSC (similarly to how it is done in mediaserver docker image https://github.com/RestComm/mediaserver-docker). We just need to use it now to configure the files in /opt/Restcomm-SMSC/jboss-5.1.0.GA/server/default/data like cassandra ip and port. Do you want to own that as well ?

[c5c86a]

@deruelle you can assign #2 (due this Wednesday) and #3 (due in 2 weeks) to me.

To avoid issues that are irrelevant to docker, I will use the current latest which is 7.3.115 and then make a PR with the latest for each of these github issues.