Testing at Openshift: Automated Testing

    This is the final part of a series of three articles ( first article , second article ), which are devoted to automated testing of software products in Openshift Origin. This article will discuss the aspects of testing in containers and the features of building CI / CD with the participation of such products as:


    1. Openshit Origin - as a system for deploying test environments.
    2. Jenkins - as a tool for continuous integration.
    3. Testlink - as a test management system.
    4. Robot Framework - as a framework for writing tests.


      For better representativeness, I prepared a Vagrant image that contains a pre-configured environment from the above products (all the objects and mechanisms listed in this article can be easily inspected). To increase the degree of understanding of the material, I created two tasks: the assembly task, the testing task. Both tasks are divided into stages and described in detail.



    Fast start:


    1. Download Vagrant Image and Vagrantfile
    2. vagrant box add --name viewshift viewshift-1.0.box && vagrant up

    Description of the environment

    Creating a full-fledged environment was not in my plans, but after losing several scenarios with linking minishift with docker containers, I realized that it was categorically inconvenient and fraught with errors. To train the imagination of readers with a single text, I consider it a futile exercise.


    By default, the environment starts in graphical mode. This is done in order to circumvent the problem of access to products from the outside. Configured automatic user login. Custom Firefox contains saved bookmarks and credentials for accessing products.


    System users user and vagrant have unlimited sudo access.


    Software involved:


    TitleVersionCredentials
    Openshift1.5.1admin: admin
    Jenkins2.60.1admin: admin
    Testlink1.9.16admin: admin
    Gogs11/0/19.0609git: git
    Mariadb5.5.52root: root
    OpenShift Pipeline Jenkins Plugin1.0.47-
    Testlink plugin3.12-
    Robot Framework plugin1.6.4-
    Post-build script plug-in0.17-
    system-root: root
    system-user: user
    system-vagrant: vagrant

    SHA1:


    0992d621809446e570be318067b70fe2b8e786b2 viewshift-1.0.box


    Assembly task:


    The build task involves building a Docker image with the curl application, which will subsequently participate in the test task.


    Note: supervisord is used as the root process (PID 1) in the container . supervisord and other similar tools are very useful in cases where you need to shut down the application completely or manage processes remotely.


    Circuit diagram:



    Stages :


    1. We define the variables that will be involved in the task:

      PROJECT - the name of the Openshift project. For this project, ServiceAccount "jenkins" was created, which has administrator rights in the project. This ServiceAccount is used to access the project from Jenkins (this account is also used in the testing task).
      APP_NAME and APP_VERSION are the conditional name and version of the application, which, however, appear in several places: the name and tag of the resulting Docker image, the name of the launched Build, etc.


    2. After the required variables have been defined (the granularity / distinctness of the tasks in the project has been thought out), it is required to distribute them across all YAML Openshift configurations and other Jenkins steps.


    3. At this stage, a BuildConfig object is created, on the basis of which a Build object will be created and executed.


    4. The build process starts based on the BuildConfig created. If successful, the resulting image will be placed in the internal Docker register.


    5. All created objects are deleted regardless of the success of the assembly.



    Testing Objective:


    The test task means the process of testing the "curl" application, which interacts with the "nginx" service via the HTTP protocol. We want to make sure that the application works correctly and passes the specified tests.


    Circuit diagram:



    Stages :


    1. We determine the parameters that will be involved in the task:

      PROJECT - the name of the Openshift project.
      TESTPLAN - the name of the test plan in Testlink. The task will fail if the specified test plan is not in Testlink.
      APP_NAME and APP_VERSION are the conditional name and version of the application, which are similarly used in the build task.
      TEST_CMD - a variable that contains the name of the executable file that will be run inside the container. Command line arguments are specified in the appropriate Jenkins step.
      TEST_TIMEOUT- a numerical expression that sets the time to wait for a command to complete inside a container. After this time, Jenkins task completes with an error.


    2. see build task.


    3. At this stage, the Testlink configuration is specified, which indicates: which server will be connected to, which test plan will be used (all the tests assigned to this test plan are downloaded from the test plan for later comparison), under which platform the testing was carried out, etc. d. All this is required for the subsequent publication of the passed tests back to Testlink and the display of the test report directly in Jenkins.


    4. This stage is intended to create a Service. The services being created will point to applications that will be launched later. Through these services, the availability of applications is checked.


    5. At this point, a Pod is created for the "nginx" application.


    6. At this point, a Pod is created for the curl application. The image for this container is the image that is created during the build task. Unlike "nginx", the data volume "share" has been added to this image, which will allow the container to communicate with the file system of the work node.


    7. After all Pods have been created, an application availability check is required through published early services.


    8. At this stage, the test command is launched in Pod and then waiting for the completion of this command.


    9. After passing all the tests, the test report is copied to the workspace of the task for subsequent import into Testlink.


    10. At this stage, a strategy is indicated (there may be more than one) for comparing the passed tests with what was obtained from the earlier test plan. In this case, there is a simple comparison of the names of test cases. After all operations, a test report is published in Testlink.


    11. In addition to the Teslink report in Junit format, there is a test report in the Robot Framework format, which will establish the status of the completed task based on the threshold values ​​of the tests passed.


    12. At this stage, all Openshift objects created during the execution of the task are deleted.



    Together:



    Advantages and disadvantages of testing in containers:


    Disadvantages:


    1. Linux only. The so-called “easy” virtualization is developing and one should probably expect changes in the situation , but so far only Linux.
    2. Единая версия ядра для всех контейнеров. Возможно в п.1
    3. Только x86_64. Нет, безусловно, ваш образ может быть x86, но ядро будет x86_64. Для кого-то это может стать препятствием.
    4. Отсутствие вложенного SELinux (вложенные CGroups существуют).
    5. Отсутствие полноценного видеоустройства и доступа к экрану. Возможно в п.1

    Плюсы:


    1. Скорость работы и гибкость запускаемых окружений, высокая плотность.
    2. Унифицированный способ доставки, переносимости и повторяемости приложений.

    Заключение:


    Openshift Origin в связке с другими инструментами позволяет добиться впечатляющей гибкости и эффективности. Продуманная схема именования проектов/объектов позволяет избежать возникновения ошибок при массовых запусках задач тестирования.


    Благодарность:


    I want to thank Google for making such a great platform.


    I want to express my gratitude to the Red Hat employees who made the finished product out of a wonderful platform.


    Useful links:


    1. Minikube - A Quick Way to Get to Know Kubernetes
    2. Minishift - A Quick Way to Get to Know Openshift
    3. Why is the IP address used instead of the FQDN for the built-in register?

    Also popular now: