New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add docker based on restcomm-connect with cassandra at localhost #1

Merged
merged 21 commits into from Jan 12, 2017

Conversation

Projects
None yet
4 participants
@nicosmaris
Contributor

nicosmaris commented Dec 30, 2016

Tested with travis

nicosmaris added some commits Dec 30, 2016

1 docker for SMSC and 1 for cassandra.
Keeps cassandra at localhost and runs dockers with --net=host

@nicosmaris nicosmaris referenced this pull request Dec 30, 2016

Closed

Docker Image for SMSC #53

@deruelle deruelle requested review from leftyb, vetss and nhanth87 Jan 3, 2017

@deruelle

This comment has been minimized.

Member

deruelle commented Jan 3, 2017

Thanks @nicosmaris !

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

@leftyb

This comment has been minimized.

Contributor

leftyb commented Jan 5, 2017

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.

@nicosmaris

This comment has been minimized.

Contributor

nicosmaris commented Jan 5, 2017

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

This comment has been minimized.

Contributor

leftyb commented Jan 5, 2017

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?

@nicosmaris

This comment has been minimized.

Contributor

nicosmaris commented Jan 5, 2017

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 ?

@nicosmaris

This comment has been minimized.

Contributor

nicosmaris commented Jan 5, 2017

@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?

@nicosmaris

This comment has been minimized.

Contributor

nicosmaris commented Jan 7, 2017

@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

This comment has been minimized.

Contributor

leftyb commented Jan 8, 2017

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

Thanks.

@leftyb

This comment has been minimized.

Contributor

leftyb commented Jan 9, 2017

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

This comment has been minimized.

Member

deruelle commented Jan 9, 2017

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

@nicosmaris

This comment has been minimized.

Contributor

nicosmaris commented Jan 9, 2017

@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

This comment has been minimized.

Contributor

leftyb commented Jan 10, 2017

@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.

@nicosmaris

This comment has been minimized.

Contributor

nicosmaris commented Jan 10, 2017

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

This comment has been minimized.

Contributor

leftyb commented Jan 10, 2017

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

This comment has been minimized.

Contributor

leftyb commented Jan 10, 2017

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

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

@leftyb

This comment has been minimized.

Contributor

leftyb commented Jan 10, 2017

@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.

@leftyb

This comment has been minimized.

Contributor

leftyb commented Jan 11, 2017

@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.

@nicosmaris

This comment has been minimized.

Contributor

nicosmaris commented Jan 11, 2017

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

This comment has been minimized.

Contributor

leftyb commented Jan 11, 2017

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

@nicosmaris

This comment has been minimized.

Contributor

nicosmaris commented Jan 11, 2017

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.

RestComm/smscgateway#53 (comment)

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

This comment has been minimized.

Contributor

leftyb commented Jan 11, 2017

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).

@leftyb

This comment has been minimized.

Contributor

leftyb commented Jan 11, 2017

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?

@nicosmaris

This comment has been minimized.

Contributor

nicosmaris commented Jan 11, 2017

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

@vetss

This comment has been minimized.

vetss commented Jan 11, 2017

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".

@nicosmaris

This comment has been minimized.

Contributor

nicosmaris commented Jan 12, 2017

@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

This comment has been minimized.

vetss commented Jan 12, 2017

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

This comment has been minimized.

Member

deruelle commented Jan 12, 2017

@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.

@leftyb leftyb merged commit 9fd2a80 into RestComm:master Jan 12, 2017

@nicosmaris

This comment has been minimized.

Contributor

nicosmaris commented Jan 12, 2017

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

This comment has been minimized.

vetss commented Jan 12, 2017

  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

This comment has been minimized.

vetss commented Jan 12, 2017

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)

@nicosmaris

This comment has been minimized.

Contributor

nicosmaris commented Jan 12, 2017

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

This comment has been minimized.

vetss commented Jan 13, 2017

@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.

@nicosmaris

This comment has been minimized.

Contributor

nicosmaris commented Jan 13, 2017

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

@nicosmaris

This comment has been minimized.

Contributor

nicosmaris commented Jan 13, 2017

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

This comment has been minimized.

vetss commented Jan 13, 2017

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 ?

@nicosmaris

This comment has been minimized.

Contributor

nicosmaris commented Jan 13, 2017

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

This comment has been minimized.

vetss commented Jan 14, 2017

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

This comment has been minimized.

Member

deruelle commented Jan 15, 2017

@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

@nicosmaris

This comment has been minimized.

Contributor

nicosmaris commented Jan 15, 2017

@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'.

jboss-dockerfiles/wildfly#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

This comment has been minimized.

Member

deruelle commented Jan 15, 2017

@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 ?

@nicosmaris

This comment has been minimized.

Contributor

nicosmaris commented Jan 16, 2017

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment