Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Stian Brattland
    @sbrattla

    @pnickolov works great with Skopos and "auto deploy". Not sure why I've been using --replace-all, but pushing new images on the latest tag does result in Skopos redeploying the service. This is great for development when you just want to rapidly push changes to a (local) swarm to do quick tests.

    If I understand correctly, yes. If in your model, you specify image: myservice:latest, then every time when a new image is published and assigned the :latest tag, Skopos will be ready to replace the component with that image.

    Tyler Evert
    @tevert
    No other issues I saw - of course, I was using "localhost:8090", so it's literally the simplest scenario. One thing I had a slight bit of trouble with was sharing the scripts directory into the skopos container - I had to pass it a full path, and I had to make sure Docker was configured to access that drive.
    And it silently failed if it didn't work; mount point just showed up empty. That's more of a Docker issue than a Skopos issue though.
    pnickolov
    @pnickolov
    @tevert Thanks!
    @/all Announcement: Skopos 0.14.18 has been released. It is a minor update to 0.14, adds support for secrets and for disabling volumes in Docker swarm
    @sbrattla We just included the ability to disable volumes from the environment file (set from: "~"); see example and details at the bottom of http://skopos-beta.datagridsys.com/plugins/docker-swarm/#volumes . Let me know if it works for you
    Stian Brattland
    @sbrattla
    @pnickolov Wow! As always, lightning fast from idea to implementation! I'll check it out!
    pnickolov
    @pnickolov
    @sbrattla, thank you! It is a useful feature, thank you for suggesting it.
    pnickolov
    @pnickolov

    @sbrattla @tevert We have a preview of an upcoming Skopos release that I think you may like. It has the following notable improvements:

    1. Support for multiple apps and an app list dashboard
    2. Deploy/replace/teardown control right from inside the app view (yes, that includes an interactive "replace-all" toggle right in the UI!)
    3. Parallel deployments
    4. Improved importing from compose files (both v2 and v3), now with automatic layout
    5. Discovering existing applications on the cluster (whether deployed by Skopos or not) - it helps to re-acquire the apps after upgrading Skopos as well as to bring under Skopos apps deployed without it. It identifies interactions/dependencies and automatically builds a graph of services and lays it out (mostly reasonably well).
      Here's a brief overview: http://skopos-beta.datagridsys.com/GET-STARTED
      Note that this is an "edge" release, still may have some rough edges; uses a separate sks-ctl utility that may not interoperate with 0.14

    I would love to hear your thoughts on this release if you have a few minutes to look at it.

    Stian Brattland
    @sbrattla
    @pnickolov you've been hard at work! I'd love to have a look at it if I can find some time (which I hopefully will be able to). I assume that the edge release use the same yaml format as the 0.14 release, and that it's only the sks-ctl utility that differs?
    pnickolov
    @pnickolov
    @sbrattla absolutely - the model/env files are fully backward compatible.
    Smailbcn
    @Smailbcn
    hi
    i have one problem

    when i click on fix, this massege comes: Fix Vulnerabilities

    There are no updates available for the selected packages from the repositories configured and enabled on this system.
    The safe repository check is currently enabled. You can change this configuration in the extension settings so that all repositories are considered valid.

    pnickolov
    @pnickolov
    Hi @Smailbcn , please contact support directly (by e-mail) or use the newly created opsani/vctr community. I will need more details to help solve the issue.
    Stian Brattland
    @sbrattla
    Hi @pnickolov, the new edge release worked great once i added --project to sks-ctl start. Starting the deploy with sks-ctl start --project api --bind 0.0.0.0:8090worked like a charm. I'm using 0.0.0.0 as I'm running Skopos as a Swarm service and this allows the Skopos container to work on all Docker hosts.
    Stian Brattland
    @sbrattla
    image.png
    Hi again @pnickolov! The user interface giving me an overview of the various projects that are "deployable" is great. It's great that Skopos can just keep an eye on the projects I've loaded. However, when I push a new image to the registry and Skopos discovers that, I can't see the model loaded for that project. The model / plan overview for that project is just blank. It does however deploy the image.
    pnickolov
    @pnickolov
    Hi @sbrattla sorry for the delay in response. This looks like a bug in the edge release. We found an issue with components missing their visual position attribute; we're fixing now, causes exactly this behavior (blank canvas). Thanks for reporting this! I'll ping you as soon as the update is out (~48h max). The workaround is to check the model yaml file and make sure each component has a visual attribute (the discovery and compose-file import automatically lay out the services but a manually edited model may not have them)
    pnickolov
    @pnickolov
    Hi @sbrattla this has been fixed - please give it another try and let me know if it still shows blank. If it does, please send details (support email ok)
    Matthias Simonis
    @unglaublicherdude

    Hi, I am running into two Issues in skopos.

    1. When I run the skopos container on on of our swarm manager nodes with this command:

      docker run --rm -d -p 8100:8100 --name skopos -v /var/run/docker.sock:/var/run/docker.sock opsani/skopos:edge

      The Webinterface will come up. When I am trying the Service Discovery it takes a while and ends with this error message:

      Discovery failed. Status: 400. Message: skopos-discover failed with err [exit status 2] and stderr [skopos-discover container non-zero exit: Command '['--stdout', '--scan-duration', '0.000', '--eye-tag', 'v1', '--discriminate-apps']' in image 'opsani/skopos-discover:v1' returned non-zero exit status 2: b'Info: creating global eye service: skopos-discover-eye-0a56557dc30627dd\nInfo: eye task scan period in minutes: 0.05\nInfo: waiting for eye tasks to transition to running state\nInfo: cycling eye service - task rejected: failed to allocate gateway (10.0.2.1): Address already in use\nInfo: destroying global eye service: skopos-discover-eye-0a56557dc30627dd\nInfo: creating global eye service: skopos-discover-eye-6c129c40fcefb9a8\n\nExiting on error: aborting - eye service task rejected: invalid mount target, must be an absolute path: /var/run/docker.sock\n\n' ]
    2. I have also tried to deploy on of our compose files that has images pointing to our internal registry. Skopos will fail the deployment with:
      ```
      retcode 1, stderr:
      ~~~
      ERROR: Error checking target image "xxx.de:6555/pt-ata-docker/mm/production/rabbitmq:latest": RegError: https://registry-1.docker.io/v2/library/xxx.de/manifests/6555/pt-ata-docker/mm/production/rabbitmq:latest: returned invalid json object: '404 page not found\n'

    ~~~
    ```

    Any on ideas If i am doing something wrong?

    pnickolov
    @pnickolov
    Hi @unglaublicherdude , looking at these now
    pnickolov
    @pnickolov
    @unglaublicherdude , you are doing everything correctly, here is an update on both issues:
    pnickolov
    @pnickolov
    #1.1. The discovery error, particularly the task rejected: failed to allocate gateway (10.0.2.1): Address already in use portion of it appears to be a docker swarm issue. We've seen it a couple of times in our own tests (with and without Skopos). What happens is that Docker assigns an IP address for one of the services the discovery tries to run and that IP address is not available (a stale state issue within Docker). Here are the two open Docker bugs reports I believe are responsible for this: moby/moby#35204 and moby/moby#35834. Note that you may see similar errors when trying to start your own services (without Skopos/discovery). The remedy is to clear the stale state in Docker. When we've seen this issue, if I recall correctly, it was due to an endpoint of a non-existing container kept in a network object; finding and deleting this unused network resolves the issue. With newer versions of Docker (which allocate IP addresses in LRU first rather than MRU first), it may be enough to just try the Discovery again. It may be worth doing docker service ls and making sure that none of the Opsani discovery services are present before running a new discover (normally, Skopos clears these out but sometimes Docker fails to do the cleanup when the stale state is present).
    #1.2. The second discovery error, eye service task rejected: invalid mount target, must be an absolute path: /var/run/docker.sock seems to be related to a failed cleanup due to the first error. Please try #1 again (after cleaning up if necessary)'
    #2. The image error is caused by an apparent bug in a Skopos Docker plugin related to parsing images with multiple directories in their name (a/b/c or a/b/c/d rather than a or a/b). Thank you for pointing this issue out! We will have a fixed version shortly.
    pnickolov
    @pnickolov
    hi @unglaublicherdude ; the image parsing should now work properly. Can you please try importing and deploying using your compose file? Please keep in mind that your private repo either needs authentication or to be marked as insecure; here is the slightly changed Skopos start command to use: http://doc.opsani.com/skopos/edge/INSTALL/#private-docker-registries (if you need to configure insecure registry instead, please LMK, the workflow is still simple but a bit different)
    Matthias Simonis
    @unglaublicherdude
    Thank you for the quick answer. I will try it again this afternoon.
    Matthias Simonis
    @unglaublicherdude

    Ok, i could test 1.1/1.2 now I am getting just the mount error without the gateway error:

    Discovery failed. Status: 400. Message: skopos-discover failed with err [exit status 2] and stderr [skopos-discover container non-zero exit: Command '['--stdout', '--scan-duration', '0.000', '--eye-tag', 'v1', '--discriminate-apps']' in image 'opsani/skopos-discover:v1' returned non-zero exit status 2: b'Info: creating global eye service: skopos-discover-eye-5639ae11dd7347d4\nInfo: eye task scan period in minutes: 0.05\nInfo: waiting for eye tasks to transition to running state\nInfo: cycling eye service - task rejected: invalid mount target, must be an absolute path: /var/run/docker.sock\nInfo: destroying global eye service: skopos-discover-eye-5639ae11dd7347d4\nInfo: creating global eye service: skopos-discover-eye-e379d8418a4a663d\n\nExiting on error: aborting - eye service task rejected: invalid mount target, must be an absolute path: /var/run/docker.sock\n\n' ]

    Triggering it again via Webinterface I get this message:

    Discovery failed. Status: 400. Message: skopos-discover failed with err [exit status 2] and stderr [aborting: skopos-discover container already running ]

    And the Service is now running.

    5e0168657c27        opsani/skopos-discover-eye:v1                                                 "./discover_srv.py"      2 minutes ago        Up About a minute                                      skopos-discover-eye-d5b37599fe61b6e6.sk5gn9sipzgu1hr7sqv1aez7f.gjytv03tp41yj9no89jgjh2xo

    A bit strange but ok. How long should I wait till the results are in the Webinterface?
    I will now test deploying a stack via the Webinterface.

    Matthias Simonis
    @unglaublicherdude
    The 2. is now working but there is still an issue.
    I loose my complete settings for resources, restart_policy and most important placement (under the deploy-section).
    We are running a multi os swarm with windows and linux hosts so I have to be able to decide on which os the service will run.
    Matthias Simonis
    @unglaublicherdude

    also I am not getting any results from the discovery service.
    Is the tool able to detect stacks, that are deployed to a docker swarm?
    The Service is now running since 39 minutes and the server within is also running:

    # netstat -tulpen
    Active Internet connections (only servers)
    Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
    tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      1/python2

    curl within the container will get results, but just from the host where the service is running.
    It is a bit odd, the discover-eye-service is running on all machines. and an inspect on the container will show:

                    "com.docker.swarm.service.name": "skopos-discover-eye-d5b37599fe61b6e6",

    But the docker engine just anwers:

    # docker service ps skopos-discover-eye-d5b37599fe61b6e6
    no such service: skopos-discover-eye-d5b37599fe61b6e6

    How would the skopos webinterface and the discover-eye-service communicate?
    They are not in put into one swarm-wide network.

    For the swarm I would most likely prefere a compose file with the discovery-eye-service configured as global service:

    version: '3'
    services:
      skopos:         
        image: opsani/skopos:edge
        networks:
          - traefik
          - default
        deploy:
          mode: replicated
          replicas: 1
          placement:
            constraints:
             - node.labels.os == linux
          labels:
           - traefik.port=8100
           - traefik.docker.network=traefik-net
      discover:
        image: opsani/skopos-discover-eye:v1
        networks:
          - default
        deploy:
          mode: global
          placement:
            constraints:
             - node.labels.os == linux
    networks:
      default:
      traefik:
        external:
          name: traefik-net
    pnickolov
    @pnickolov
    @unglaublicherdude , thank you for trying it out. Both the discover and the compose file import have some limitations and may not support automatically detecting advanced settings (like resources and placement). However, these can be added manually (unless you have lots of services - I will bump support for these fields in the backlog just in case). Once you import the compose file, you can switch to edit mode (Edit and then press Edit All on the property sheet) or simply edit the Skopos model using the web YAML editor from the {} button (or your own code editor). You can see examples of resources and placement constraints here: http://doc.opsani.com/skopos/edge/plugins/docker-swarm/#plugin-specific-component-attributes, section plugin. I will check on the restart policy and post it here (anything in the raw section is in the form of the Docker API objects). You don't need to specify all the attributes listed in the example, just the ones you want to use.
    pnickolov
    @pnickolov
    @unglaublicherdude it seems like we're in opposite time zones; I have asked one of our engineers who is in your part of the world to keep an eye on this thread so we can help quickly. You can also reach us on support@opsani.com - if any further help is needed, we can simply set up a skype or hangouts call as well and get you going.
    pnickolov
    @pnickolov

    @unglaublicherdude following up on the restart policy - it is also possible to specify your custom restart policy. See the link above for the other attributes (placement, resources). The restart policy for swarm services can be specified in the raw section, under TaskTemplate as 'RestartPolicy:' (at the same level as the Placement: attribute) . The sub-attributes are the same as in the compose file, but use the API-style naming: Condition (none|on-failure|any), MaxAttempts (integer, 0 is ignored), Delay and Window ( integers, likely in nanoseconds, whatever units docker API uses, I can check if needed).

    Combining resources, restart policy and placement, the attributes in the Skopos model file would look like this:

    components:
       web:
          ...
          plugin:
             docker-swarm:
                cpu_reservation: 1
                cpu_limit: 2
                mem_reservation: 300m
                mem_limit: 1g
                raw:
                   TaskTemplate:
                      Placement:
                         Constraints: ["node.role==manager"]
                      RestartPolicy:
                         Condition: on-failure
                         MaxAttempts: 5

    LMK if this is clear enough/need further info on how to set the attributes that the compose importer doesn't support yet.

    pnickolov
    @pnickolov
    Note that the reason these settings are in the plugin-specific section is because the set and values of these attributes are dependent on the target orchestator (i.e., they differ between plain Docker containers, swarm services, kubernetes, etc.). If you deploy to more than one of these environments, you may have multiple sections
    Matthias Simonis
    @unglaublicherdude
    Ah. That sounds great. I will test it when I have time. Approximately at the start of next week, I think.
    I really appreciate your dedication to the questions here!
    pnickolov
    @pnickolov
    FYI, variable substitution is now supported not only in the models but also in the plugin_config section in environment files. See http://doc.opsani.com/skopos/edge/TED-REF/#variables section for details. This allows using variables for VM instance type (e.g., for EC2) as well as for volume bindings, secrets, etc., configuration values for containers (in the Docker and Kubernetes environments).
    pnickolov
    @pnickolov

    @/all NOTE: Upcoming backward-incompatible change in the ec2-asg plugin (affects only deployments using this plugin).

    We will be changing the ec2-asg plugin to use the new AWS EC2 launch template (LT) feature instead of launch configuration (LC) feature for the template attribute. This change will enable use of the advanced features that LTs make available. I believe we have reached out to everyone using the ec2-asg plugin prior to this notice to plan for the transition.

    The new version will be rolled out within the next week into the edge release of Skopos. The stable release will not be affected until the next stable release. If you have any questions or concerns, please contact Opsani support.

    WorldOfMadness
    @worldofmadness
    Support for debian 9 on plesk
    17.8.11
    Is there any?
    Stefana Muller
    @stefana912
    VCTR Plesk Extension doesn’t support Debian9.
    itinkoff
    @itinkoff
    Hi, on CentOS 6 Opsani incorrectly reports Apache vulnerabilities. It tells that it is vulnerable to CVE-2017-7679: In Apache httpd 2.2.x before 2.2.33 and 2.4.x before 2.4.26, mod_mime can read one byte past the end of a buffer when sending a malicious Content-Type response header. While CentOS backported that to 2.2.15: https://access.redhat.com/security/updates/backporting
    ]# rpm -q --changelog httpd | grep CVE-2017-7679
    • Resolves: #1463207 - CVE-2017-7679 httpd: mod_mime buffer overread

    plesk version

    Product version: Plesk Onyx 17.8.11 Update #10
    OS version: CentOS 6.9
    Architecture: 64-bit
    the same true for the bunch of vulnerabilities: CVE-2017-3169, CVE-2017-3167, CVE-2017-9798, CVE-2017-9788
    the same for ntp package
    CVE-2017-6464, CVE-2017-6463, CVE-2017-6462
    Stefana Muller
    @stefana912
    Hi @itinkoff - this channel is about Skopos. I've posted your question to the VCTR channel for our team to get back to you. Please go there...