Repository files navigation

HTTP/1 mock server built with Python Flask and supported by docker/kubernetes.

This image is already available atdocker hub for every repositorytag, and also for master aslatest:

$ docker pull testillano/h1mock:<tag>

You could also build it using the script./build.sh located at project root:

./build.sh

This image is built with./Dockerfile.

h1mock is delivered in ahelm chart calledh1mock (./helm/h1mock) so you may integrate it in your regularhelm chart deployments by just adding a few artifacts.

1. Add the project's helm repository with aliaserthelm:

    helm repo add erthelm https://testillano.github.io/helm

2. Add one dependency to yourChart.yaml file per each service you want to mock withh1mock service (use alias when two or more dependencies are included).

   dependencies:  -name:h1mockversion:1.0.0repository:alias:erthelmalias:server1  -name:h1mockversion:1.0.0repository:alias:erthelmalias:server2

3. Refer toh1mock values through the corresponding dependency alias, for example.Values.h1server.image to access process repository and tag.

The application is built on demand from pieces of source code which define the server behavior. The implementation must follow theflask API referring to anapp application (this instance name is mandatory, no other can be used).

The needed code only requires the definition of theURL rules inside a function which must be calledregisterRules() and also the functions required by those rules. For example:

defregisterRules():app.add_url_rule("/foo","foo_get",view_func=foo_get,methods=['GET'])app.add_url_rule("/bar","bar_post",view_func=bar_post,methods=['POST'])deffoo_get:# <here your code>defbar_post:# <here your code>

Summing up,these are the requirements:

• Flask application instance:app.

• Mandatory rules registration definition:registerRules().

• No need to re-import those already available:os,logging and of course,flask (Flask,Blueprint,jsonify,request).

• Also, you have available the flask APIstatus codes.

• The piece of source code must not be indented on first level (definitions), and although it is not mandatory, 2-spaces are recommended for inner tabs.

• Files within your deployedconfigmap shall be accessible under directory path/app/provision (or justprovision as/app is the mock image working directory). This is useful if you consider to load auxiliary files (json or any other format) from your mock source code implementation.

More examples could be found at./examples directory.

To configure the service, that source code could be provisioned in two ways:

The chart valueservice.provisionsDir could be used to specify a directory path where provision files are installed at deployment time. From these files, the one named 'initial' will be used as the working provision after deployment (symlink it to any of them or just name it so), and the rest are available for further optional activation operations (touch). A default 'initial' provision (which always responds status code404 Not Found with anhtml response containing a help hyper link) will be created asfall back when no initial provision is found during deployment.

Provisions must be accessible fromhelm chart root level and aConfigMap must be created for them using theh1mock.configmap function fromh1mock charttemplates/_helpers.tpl. For example:

$> tree examplesexamples├── default├── foo-bar├── healthz└── initial -> default$>cd helm/h1mock$> ln -sf ../../examples$> cat<<EOF > templates/provision-config.yaml{{- include "h1mock.configmap" ( list $ $.Values ) }}EOF$> kubectl create namespace h1m$> helm install h1m -n h1m. --set service.provisionsDir=examples --wait$> POD=$(kubectl get pods -n h1m --no-headers| awk'{ if ($3 == "Running") print $1 }')$> kubectlexec -it -n h1m${POD} -- sh -c"ls /app/provision"default  foo-bar  healthz  initial$> helm delete -n h1m h1m$> kubectl delete namespace h1m

All these steps have been done in component test chart (./helm/ct-h1mock) which has aConfigMap already created and also a specific provisions directory enabled atvalues.yaml file.

This can be done in two main ways:

• Throughkubectl cp of the source file intoh1mock container's path/app/provision. The utilityinotify will detect the creation event to upgrade the server source activating the new behavior. You could send different server definitions and they will be loaded on demand (this is thanks toflask debug mode option). You could even reactivate any of the available provision files within the docker internal directory, by mean touching them by meankubectl exec.
• Through an administrative service which is launched on valueservice.admin_port (8074 by default). These are the supported methods of this control API:
  • POST/app/v1/provision/<file basename> with source code sent over the request body in plain text. This operation always receives status code201 Created, but possible crash of container's application may be provoked by a bad design of the content sent (in that case, the 'initial' provision will be restored).
  • GET/app/v1/provision/<file basename>, to "touch" and so reactivate an existing provision. This also receives200 OK, even when the touched provision was missing: in that case, an empty provision is created and this shall provoke the crash, being a rude way to reboot the container and then, restore the initial configuration.
  • There is also a keep-alive for administration interface, viaGET/healthz. This could be used to check that the provision system throughHTTP/1 interface is available.

To deploy the main micro service chart, execute the following:

./deploy.sh

Once installed, a template notes will be shown. Follow the instructions to execute manually a basic check.

The following script will deploy the component test chart and then start the pytest framework:

./ct/test.sh

External provision by meankubectl commands is tested too, but usingbash instead ofpytest:

./ct/ktest.sh