Giter Site home page Giter Site logo

deis / controller Goto Github PK

View Code? Open in Web Editor NEW
41.0 15.0 53.0 16.6 MB

Deis Workflow Controller (API)

Home Page: https://deis.com

License: MIT License

Makefile 0.37% Python 99.07% Shell 0.56%
kubernetes django-rest-framework rest-api python3 k8s deis-workflow unsupported

controller's Introduction

Deis Workflow is no longer maintained.
Please read the announcement for more detail.
09/07/2017 Deis Workflow v2.18 final release before entering maintenance mode
03/01/2018 End of Workflow maintenance: critical patches no longer merged
Hephy is a fork of Workflow that is actively developed and accepts code contributions.

Deis Controller

Build Status codecov.io Docker Repository on Quay Dependency Status

Deis (pronounced DAY-iss) Workflow is an open source Platform as a Service (PaaS) that adds a developer-friendly layer to any Kubernetes cluster, making it easy to deploy and manage applications on your own servers.

For more information about the Deis Workflow, please visit the main project page at https://github.com/deis/workflow.

We welcome your input! If you have feedback, please submit an issue. If you'd like to participate in development, please read the "Development" section below and submit a pull request.

About

The Controller is the central API server for Deis Workflow. It is installed on a Kubernetes cluster, making it easy to deploy and manage applications on your own cluster. Below is a non-exhaustive list of things it can do:

  • Create a new application
  • Delete an application
  • Scale an application
  • Configure an application
  • Create a new user

Development

The Deis project welcomes contributions from all developers. The high-level process for development matches many other open source projects. See below for an outline.

  • Fork this repository
  • Make your changes
  • Submit a pull request (PR) to this repository with your changes, and unit tests whenever possible.
    • If your PR fixes any issues, make sure you write Fixes #1234 in your PR description (where #1234 is the number of the issue you're closing)
  • Deis project maintainers will review your code.
  • After two maintainers approve it, they will merge your PR.

Prerequisites

Docker

Unit tests and code linters for controller run in a Docker container with your local code directory mounted in. You need Docker to run make test.

Kubernetes

You'll want to test your code changes interactively in a working Kubernetes cluster. Follow the installation instructions if you need Kubernetes.

Workflow Installation

After you have a working Kubernetes cluster, you're ready to install Workflow.

Testing Your Code

When you've built your new feature or fixed a bug, make sure you've added appropriate unit tests and run make test to ensure your code works properly.

Also, since this component is central to the platform, it's recommended that you manually test and verify that your feature or fix works as expected. To do so, ensure the following environment variables are set:

  • DEIS_REGISTRY - A Docker registry that you have push access to and your Kubernetes cluster can pull from
    • If this is Docker Hub, leave this variable empty
    • Otherwise, ensure it has a trailing /. For example, if you're using Quay.io, use quay.io/
  • IMAGE_PREFIX - The organization in the Docker repository. This defaults to deis, but if you don't have access to that organization, set this to one you have push access to.
  • SHORT_NAME (optional) - The name of the image. This defaults to controller
  • VERSION (optional) - The tag of the Docker image. This defaults to the current Git SHA (the output of git rev-parse --short HEAD)

Then, run make deploy to build and push a new Docker image with your changes and replace the existing one with your new one in the Kubernetes cluster. See below for an example with appropriate environment variables.

export DEIS_REGISTRY=quay.io/
export IMAGE_PREFIX=arschles
make deploy

After the make deploy finishes, a new pod will be launched but may not be running. You'll need to wait until the pod is listed as Running and the value in its Ready column is 1/1. Use the following command watch the pod's status:

kubectl get pod --namespace=deis -w | grep deis-controller

controller's People

Contributors

aledbf avatar arschles avatar babarinde avatar bengrunfeld avatar carmstrong avatar croemmich avatar glogiotatidis avatar helgi avatar iancoffey avatar jgmize avatar johanneswuerbach avatar joshua-anderson avatar kalbasit avatar kmala avatar krancour avatar mboersma avatar nathansamson avatar ngpestelos avatar progrium avatar romansergey avatar seanknox avatar sedouard avatar slack avatar smothiki avatar technosophos avatar tombh avatar tscheepers avatar vdice avatar wenzowski avatar xe avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

controller's Issues

Document how to configure deis and git clients

There should be a document that outlines how to configure the deis and git clients for at least the following Deis installation kinds:

  1. When Deis is helm installed onto a k8s cluster running on a load balancer capable cloud provider
  2. When Deis is helm installed onto a k8s cluster running on infrastructure where external load balancer creation is a no-op (e.g. bare metal or virtualbox)
  3. When only workflow and builder are running (this will require app creation against the workflow cluster IP, then setting up a git remote directly to the builder cluster IP)

This issue follows from deis/router#58.

Buildpack build of `example-ruby-sinatra` dies because controller wants a Docker image.

When I try to deploy example-ruby-sinatra, the build fails with a 500 from Controller.

In the logs, the problem seems to be that controller is trying to find an image for a buildpack release even though the builder does not build images for buildpacks (it just builds slugs and runs the slugrunner):

⇒  k --namespace=deis logs deis-workflow-o2uml
waiting for etcd at 10.247.174.157:4100...
addgroup: gid '0' in use
Syncing...
Creating tables ...
Creating table django_admin_log
Creating table auth_permission
Creating table auth_group_permissions
Creating table auth_group
Creating table auth_user_groups
Creating table auth_user_user_permissions
Creating table auth_user
Creating table django_content_type
Creating table django_session
Creating table django_site
Creating table django_auth_ldap_testuser
Creating table django_auth_ldap_testprofile
Creating table south_migrationhistory
Creating table corsheaders_corsmodel
Installing custom SQL ...
Installing indexes ...
Installed 0 object(s) from 0 fixture(s)
Migrating...
Running migrations for authtoken:
 - Migrating forwards to 0001_initial.
 > authtoken:0001_initial
 - Loading initial data for authtoken.
Installed 0 object(s) from 0 fixture(s)
Running migrations for api:
 - Migrating forwards to 0025_auto__chg_field_app_id.
 > guardian:0001_initial
 > guardian:0002_auto__add_field_groupobjectpermission_object_pk__add_field_userobjectp
 > guardian:0003_update_objectpermission_object_pk
 > guardian:0004_auto__del_field_groupobjectpermission_object_id__del_unique_groupobjec
 > guardian:0005_auto__chg_field_groupobjectpermission_object_pk__chg_field_userobjectp
 > api:0001_initial
 > api:0002_drop_djcelery
 > api:0003_drop_socialaccount
 > api:0004_add_custom_perms
 > api:0005_auto__add_push__add_unique_push_app_uuid
 > api:0006_auto__add_field_release_summary
 > api:0007_auto__del_flavor__del_unique_flavor_owner_id__del_layer__del_unique_la
 > api:0008_auto__add_field_release_image
 > api:0009_auto__chg_field_container_state
 > api:0010_auto__add_field_build_sha__add_field_build_procfile__add_field_build_d
 > api:0011_auto__add_domain
 > api:0012_auto__add_limit__add_unique_limit_app_uuid__add_field_config_limit
 > api:0013_auto__del_limit__del_unique_limit_app_uuid__del_field_config_limit__ad
 > api:0014_auto__add_field_config_tags
 > api:0015_migration_config_defaults
 > api:0016_drop_allauth
 > api:0017_auto__del_cluster__del_field_app_cluster
 > api:0018_drop_field_release_image__chg_field_release_build
 > api:0019_fix_dockerfile_empty_value
 > api:0020_auto__del_field_container_state
 > api:0021_auto__add_certificate
 > api:0022_auto__add_field_key_fingerprint
 > api:0023_key_fingerprints
 > api:0024_auto__chg_field_key_fingerprint__del_unique_key_owner_id__add_unique_k
 > api:0025_auto__chg_field_app_id
 - Loading initial data for api.
Installed 0 object(s) from 0 fixture(s)
Running migrations for guardian:
- Nothing to migrate.
 - Loading initial data for guardian.
Installed 0 object(s) from 0 fixture(s)

Synced:
 > django.contrib.admin
 > django.contrib.auth
 > django.contrib.contenttypes
 > django.contrib.humanize
 > django.contrib.messages
 > django.contrib.sessions
 > django.contrib.sites
 > django.contrib.staticfiles
 > django_auth_ldap
 > json_field
 > rest_framework
 > south
 > corsheaders
 > registry
 > web

Migrated:
 - rest_framework.authtoken
 - api
 - guardian
[2015-12-16 22:31:10 +0000] [128] [INFO] Starting gunicorn 19.3.0
[2015-12-16 22:31:10 +0000] [128] [INFO] Listening at: http://0.0.0.0:8000 (128)
[2015-12-16 22:31:10 +0000] [128] [INFO] Using worker: sync
[2015-12-16 22:31:10 +0000] [132] [INFO] Booting worker with pid: 132
[2015-12-16 22:31:10 +0000] [133] [INFO] Booting worker with pid: 133
[2015-12-16 22:31:10 +0000] [134] [INFO] Booting worker with pid: 134
Publishing DB state to etcd...
[2015-12-16 22:31:10 +0000] [135] [INFO] Booting worker with pid: 135
Done Publishing DB state to etcd.
deis-controller running...
[2015-12-16 22:31:10 +0000] [140] [INFO] Booting worker with pid: 140
[2015-12-16 22:31:10 +0000] [141] [INFO] Booting worker with pid: 141
[2015-12-16 22:31:10 +0000] [142] [INFO] Booting worker with pid: 142
[2015-12-16 22:31:11 +0000] [143] [INFO] Booting worker with pid: 143
[2015-12-16 22:31:11 +0000] [144] [INFO] Booting worker with pid: 144
WARNING Not Found: /
10.246.29.1 "GET / HTTP/1.1" 404 74 "curl/7.43.0"
10.246.29.1 "GET /v2/ HTTP/1.1" 401 58 "Deis Client v2.0.0-dev"
10.246.29.1 "POST /v2/auth/register/ HTTP/1.1" 400 42 "Deis Client v2.0.0-dev"
10.246.29.1 "GET /v2/ HTTP/1.1" 401 58 "Deis Client v2.0.0-dev"
10.246.29.1 "POST /v2/auth/register/ HTTP/1.1" 201 251 "Deis Client v2.0.0-dev"
10.246.29.1 "POST /v2/auth/login/ HTTP/1.1" 200 52 "Deis Client v2.0.0-dev"
10.246.29.1 "POST /v2/keys/ HTTP/1.1" 201 653 "Deis Client v2.0.0-dev"
INFO hearty-checkers: config hearty-checkers-a45a22b updated
INFO hearty-checkers: release hearty-checkers-v1 created
INFO [hearty-checkers]: matt created initial release
10.246.29.1 "POST /v2/apps/ HTTP/1.1" 201 204 "Deis Client v2.0.0-dev"
10.246.29.1 "POST /v2/hooks/push HTTP/1.1" 201 442 "curl/7.39.0"
10.246.29.1 "POST /v2/hooks/config HTTP/1.1" 200 199 "deis-builder"
INFO hearty-checkers: build hearty-checkers-eaa6fc1 created
INFO hearty-checkers: release hearty-checkers-v2 created
INFO [hearty-checkers]: matt deployed e159088
INFO Pulling Docker image 10.247.243.26:5000/hearty-checkers:git-e1590887
ERROR Internal Server Error: /v2/hooks/build
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/django/core/handlers/base.py", line 112, in get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/usr/lib/python2.7/site-packages/django/views/decorators/csrf.py", line 57, in wrapped_view
    return view_func(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/rest_framework/viewsets.py", line 85, in view
    return self.dispatch(request, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/rest_framework/views.py", line 407, in dispatch
    response = self.handle_exception(exc)
  File "/usr/lib/python2.7/site-packages/rest_framework/views.py", line 404, in dispatch
    response = handler(request, *args, **kwargs)
  File "/app/api/views.py", line 403, in create
    super(BuildHookViewSet, self).create(request, *args, **kwargs)
  File "/app/api/views.py", line 129, in create
    return super(BaseDeisViewSet, self).create(request, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/rest_framework/mixins.py", line 21, in create
    self.perform_create(serializer)
  File "/app/api/viewsets.py", line 21, in perform_create
    self.post_save(obj)
  File "/app/api/views.py", line 410, in post_save
    build.create(self.user)
  File "/app/api/models.py", line 736, in create
    source_version=source_version)
  File "/app/api/models.py", line 849, in new
    release.publish()
  File "/app/api/models.py", line 865, in publish
    publish_release(source_image, self.config.values, self.image, deis_registry)
  File "/app/registry/dockerclient.py", line 118, in publish_release
    return client.publish_release(source, config, target, deis_registry)
  File "/app/registry/dockerclient.py", line 42, in publish_release
    self.pull(repo, src_tag)
  File "/app/registry/dockerclient.py", line 74, in pull
    log_output(stream)
  File "/app/registry/dockerclient.py", line 106, in log_output
    raise docker.errors.DockerException(chunk)
DockerException: {"errorDetail":{"message":"Error: image hearty-checkers:git-e1590887 not found"},"error":"Error: image hearty-checkers:git-e1590887 not found"}

10.246.29.1 "POST /v2/hooks/build HTTP/1.1" 500 27 "deis-builder"

The full record of what I did to produce this is here: https://gist.github.com/technosophos/773167a92d11ca1edbf9

server error talking to controller when launching during a `git push` based deploy

On a git push from the example-go repo (a buildpack build), the following output results:

ENG000656:example-go aaronschlesinger$ git push deis master
The authenticity of host '[deis.micro-kube.local]:2222 ([172.17.8.100]:2222)' can't be established.
ECDSA key fingerprint is SHA256:0ZiwB2heubH7jTpArCHN6Mf009u6TtgDDS99ZwUg/KM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[deis.micro-kube.local]:2222,[172.17.8.100]:2222' (ECDSA) to the list of known hosts.
Counting objects: 75, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (40/40), done.
Writing objects: 100% (75/75), 18.20 KiB | 0 bytes/s, done.
Total 75 (delta 30), reused 75 (delta 30)
Added host ‘http://10.3.0.36:9000’ successfully.
mc: <ERROR> Unable to make bucket ‘http://10.3.0.36:9000/git’. The requested bucket name is not available.
‘wicker-radiator.tar.gz’ -> ‘http://10.3.0.36:9000/git/home/wicker-radiator:git-5450cbcd/tar’
Total: 2.76 KB, Transferred: 2.76 KB, Speed: 820.28 KB/s
-----> stored tarfile in http://10.3.0.36:9000/git/home/wicker-radiator:git-5450cbcd/tar
-----> creating builder pod in namespace deis
pod "wicker-radiator-git-5450cbcd" created
Waiting for build to complete...
............................................................
Build complete.
-----> Launching... 
2015/12/16 19:29:58 failed retrieving config from controller: <h1>Server Error (500)</h1>
To ssh://[email protected]:2222/wicker-radiator.git
 * [new branch]      master -> master

Note the following:

  1. I was able to successfully push and launch a new app yesterday evening
  2. This push was done on a fresh deis cluster, fresh app
  3. The first two pushes failed, and I saw a traceback in workflow logs (see below), but subsequent pushes seem to succeed.
10.2.76.1 "POST /v2/hooks/build HTTP/1.1" 500 27 "deis-builder"
10.2.76.1 "GET /v2/ HTTP/1.1" 401 58 "Deis Client v2.0.0-dev"
10.2.76.1 "POST /v2/auth/register/ HTTP/1.1" 400 43 "Deis Client v2.0.0-dev"
10.2.76.1 "GET /v2/ HTTP/1.1" 401 58 "Deis Client v2.0.0-dev"
10.2.76.1 "POST /v2/auth/login/ HTTP/1.1" 200 52 "Deis Client v2.0.0-dev"
10.2.76.1 "POST /v2/keys/ HTTP/1.1" 201 983 "Deis Client v2.0.0-dev"
10.2.76.1 "POST /v2/keys/ HTTP/1.1" 400 41 "Deis Client v2.0.0-dev"
INFO wicker-radiator: config wicker-radiator-fe4aa59 updated
INFO wicker-radiator: release wicker-radiator-v1 created
INFO [wicker-radiator]: arschles created initial release
10.2.76.1 "POST /v2/apps/ HTTP/1.1" 201 208 "Deis Client v2.0.0-dev"
10.2.76.1 "POST /v2/hooks/push HTTP/1.1" 201 448 "curl/7.39.0"
10.2.76.1 "POST /v2/hooks/config HTTP/1.1" 200 203 "deis-builder"
INFO wicker-radiator: build wicker-radiator-630cd8a created
INFO wicker-radiator: release wicker-radiator-v2 created
INFO [wicker-radiator]: arschles deployed 5450cbc
INFO Pulling Docker image 10.3.0.185:5000/wicker-radiator:git-5450cbcd
INFO wicker-radiator: 500 Server Error: Internal Server Error ("invalid registry endpoint https://10.3.0.185:5000/v0/: unable to ping registry endpoint https://10.3.0.185:5000/v0/
v2 ping attempt failed with error: Get https://10.3.0.185:5000/v2/: tls: oversized record received with length 20527
 v1 ping attempt failed with error: Get https://10.3.0.185:5000/v1/_ping: tls: oversized record received with length 20527. If this private registry supports only HTTP or HTTPS with an unknown CA certificate, please add `--insecure-registry 10.3.0.185:5000` to the daemon's arguments. In the case of HTTPS, if you have access to the registry's CA certificate, no need for the flag; simply place the CA certificate at /etc/docker/certs.d/10.3.0.185:5000/ca.crt")
INFO [wicker-radiator]: 500 Server Error: Internal Server Error ("invalid registry endpoint https://10.3.0.185:5000/v0/: unable to ping registry endpoint https://10.3.0.185:5000/v0/
v2 ping attempt failed with error: Get https://10.3.0.185:5000/v2/: tls: oversized record received with length 20527
 v1 ping attempt failed with error: Get https://10.3.0.185:5000/v1/_ping: tls: oversized record received with length 20527. If this private registry supports only HTTP or HTTPS with an unknown CA certificate, please add `--insecure-registry 10.3.0.185:5000` to the daemon's arguments. In the case of HTTPS, if you have access to the registry's CA certificate, no need for the flag; simply place the CA certificate at /etc/docker/certs.d/10.3.0.185:5000/ca.crt")
INFO wicker-radiator: arschles scaled containers web=1
INFO [wicker-radiator]: arschles scaled containers web=1
DEBUG scale wicker-radiator_v2.web, img wicker-radiator:v2, params {u'num': 1, u'tags': {}, u'aname': u'wicker-radiator', u'version': u'v2', u'memory': {}, u'cpu': {}}, cmd "start web"
DEBUG create wicker-radiator_v2.web, img wicker-radiator:v2, params {u'version': u'v2', u'tags': {}, u'aname': u'wicker-radiator', u'num': 1, u'memory': {}, u'cpu': {}}, cmd "start web"
ERROR wicker-radiator: wicker-radiator_v2.web (scale): u'containerID'
ERROR [wicker-radiator]: wicker-radiator_v2.web (scale): u'containerID'
ERROR Internal Server Error: /v2/hooks/build
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/django/core/handlers/base.py", line 112, in get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/usr/lib/python2.7/site-packages/django/views/decorators/csrf.py", line 57, in wrapped_view
    return view_func(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/rest_framework/viewsets.py", line 85, in view
    return self.dispatch(request, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/rest_framework/views.py", line 407, in dispatch
    response = self.handle_exception(exc)
  File "/usr/lib/python2.7/site-packages/rest_framework/views.py", line 404, in dispatch
    response = handler(request, *args, **kwargs)
  File "/app/api/views.py", line 403, in create
    super(BuildHookViewSet, self).create(request, *args, **kwargs)
  File "/app/api/views.py", line 129, in create
    return super(BaseDeisViewSet, self).create(request, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/rest_framework/mixins.py", line 21, in create
    self.perform_create(serializer)
  File "/app/api/viewsets.py", line 21, in perform_create
    self.post_save(obj)
  File "/app/api/views.py", line 410, in post_save
    build.create(self.user)
  File "/app/api/models.py", line 738, in create
    self.app.deploy(user, new_release)
  File "/app/api/models.py", line 466, in deploy
    self._default_scale(user, release)
  File "/app/api/models.py", line 510, in _default_scale
    self.scale(user, structure)
  File "/app/api/models.py", line 296, in scale
    self._scale_containers(scale_types, to_remove)
  File "/app/api/models.py", line 329, in _scale_containers
    **kwargs
  File "/app/scheduler/k8s.py", line 295, in scale
    self.create(name, image, command, **kwargs)
  File "/app/scheduler/k8s.py", line 406, in create
    self._create_service(name, app_name, app_type, data)
  File "/app/scheduler/k8s.py", line 436, in _create_service
    container_id = actual_pod['status']['containerStatuses'][0]['containerID'].split("//")[1]
KeyError: u'containerID'
10.2.76.1 "POST /v2/hooks/build HTTP/1.1" 500 27 "deis-builder"
10.2.76.1 "POST /v2/hooks/push HTTP/1.1" 201 448 "curl/7.39.0"
10.2.76.1 "POST /v2/hooks/config HTTP/1.1" 200 203 "deis-builder"
INFO wicker-radiator: build wicker-radiator-52947c0 created
INFO wicker-radiator: release wicker-radiator-v3 created
INFO [wicker-radiator]: arschles deployed 6b2d12b
INFO Pulling Docker image 10.3.0.185:5000/wicker-radiator:git-6b2d12b8
INFO wicker-radiator: 500 Server Error: Internal Server Error ("invalid registry endpoint https://10.3.0.185:5000/v0/: unable to ping registry endpoint https://10.3.0.185:5000/v0/
v2 ping attempt failed with error: Get https://10.3.0.185:5000/v2/: tls: oversized record received with length 20527
 v1 ping attempt failed with error: Get https://10.3.0.185:5000/v1/_ping: tls: oversized record received with length 20527. If this private registry supports only HTTP or HTTPS with an unknown CA certificate, please add `--insecure-registry 10.3.0.185:5000` to the daemon's arguments. In the case of HTTPS, if you have access to the registry's CA certificate, no need for the flag; simply place the CA certificate at /etc/docker/certs.d/10.3.0.185:5000/ca.crt")
INFO [wicker-radiator]: 500 Server Error: Internal Server Error ("invalid registry endpoint https://10.3.0.185:5000/v0/: unable to ping registry endpoint https://10.3.0.185:5000/v0/
v2 ping attempt failed with error: Get https://10.3.0.185:5000/v2/: tls: oversized record received with length 20527
 v1 ping attempt failed with error: Get https://10.3.0.185:5000/v1/_ping: tls: oversized record received with length 20527. If this private registry supports only HTTP or HTTPS with an unknown CA certificate, please add `--insecure-registry 10.3.0.185:5000` to the daemon's arguments. In the case of HTTPS, if you have access to the registry's CA certificate, no need for the flag; simply place the CA certificate at /etc/docker/certs.d/10.3.0.185:5000/ca.crt")
DEBUG deploy wicker-radiator_v3.web, img wicker-radiator:v3, params {u'version': u'v3', u'tags': {}, u'aname': u'wicker-radiator', u'num': 0, u'memory': {}, u'cpu': {}}, cmd "start web"
INFO wicker-radiator: arschles scaled containers web=1
INFO [wicker-radiator]: arschles scaled containers web=1
10.2.76.1 "POST /v2/hooks/build HTTP/1.1" 200 65 "deis-builder"

docs: Document adding domain annotation before helm install

Right now the current docs suggest running a straight Helm install.

https://github.com/deis/workflow/blob/master/docs/src/installing-deis/installing-the-deis-platform.md

In practice, the Deis router is not ready out of the box. So the current workflow that I have to use is this:

$ helm fetch deis/deis
$ vi $(helm home)/workspace/deis/manifest/deis-router-rc.yaml
$ helm install deis

In the second step, I have to do something like this:

apiVersion: v1
kind: ReplicationController
metadata:
  name: deis-router
  namespace: deis
  labels:
    heritage: deis
  annotations:
    deis.io/routerConfig: |
      {
        "domain": "10.245.1.3.xip.io",
        "useProxyProtocol": false
      }

Unless there is a better workaround, this seems to be required to get any deis cluster working.

/cc @krancour

Port integration tests to deis/workflow

The existing deis/deis integration tests still largely apply to the Deis v2 workflow, and they should constitute the acceptance criteria for the alpha release.

replace confd templating with kubernetes service discovery

In v1 we published the components using a publishing loop, which would push host/port information into etcd. We would then template out the host/port using confd, and that was our service discovery. In v2, kubernetes has service discovery baked in so this is no longer necessary. However, we still need confd for things like LDAP auth support.

ship a v2 client for testing

now that we've merged #58, the default install docs no longer work because curl -sSL http://deis.io/deis-cli/install.sh | sh will install v1.12.2. What we need is for _scripts/deploy.sh to ship a v2 client :)

minio & off-cluster storage

to accomplish #3, workflow needs to check the following in order:

  • minio service environment variables
  • off cluster storage environment variable (e.g. DEIS_OFF_CLUSTER_OBJECT_STORAGE_URL)
  • fetcher URL

Bold proposal. Rewrite controller in go

This could be accomplished by doing it similarly as the client.
Rewrite piece by piece, and if specific feature is not implemented yet let the new implementatio proxy the call to the legacy controller.

Ideally both will run side by side (I know this is frowned upon a bit) in same container, but the legacy one would listen on localhost only. ( I assume this means its not reachable from any other place).

Remove some of the scheduling abstraction in favour of more tightly coupled model <-> k8s integration

Right now all the model code has to interact with the scheduler via a thin and very constraint scheduler.k8s and scheduler.abstract API which includes very simple constructs such as start, create, destroy, deploy, scale and so on.

This is a hangover from when we had many schedulers and we were catering to the lowest common denominator and doing things in a very simplistic manner to reduce the surface area of models <-> scheduler interaction.

An example of that is when deis apps:create is ran then the only way k8s:service is created is when a scale event is triggered and internal to that scheduling code it is discovered that ReplicationController and Service is missing for the given app, the scheduling code creates those and then continues to scale from 0 to 1.

The above makes it very hard for us to appropriately hook into the k8s life cycle to drop annotations (such as domain information) to an existing Service without teaching Domain model how to create Services in addition to update. Keeping with the Domain example I have had to teach Domain minimal k8s-fu to store information.

This was all much simpler with etcd due to a far more adhoc nature. Drop a key, confd picks it up and does stuff with it somewhere. Full k8s integration is forcing us to think about models differently

By bringing k8s up one layer and giving models more direct access then we can keep the k8s-client clean and potentially separated out from workflow. This would involve bringing back #48, fixing it up and extending it so models can use it easily.

  • Is this something we want to invest in?
  • Is it bad to bring more awareness of k8s up into the models?
  • How will we do the tests (we never really integrated etcd into the tests as an example)?

Set env vars in rc or pod manifest

Instead of doing a programmatic docker build to add on last-mile environment variables, the k8s.py scheduler code could instead add them to the configuration / manifest it creates. docker.sock would still be necessary to pull images and push them to deis-registry, but this could be simpler and more efficient for the last-mile layer.

docs: quickstart skips installing client

If you follow the quickstart guide, you get to docs/src/installing-deis/installing-the-deis-platform.md, which walks through server setup, then directs you to docs/src/using-deis/deploying-an-application.md.

Neither covers or points to the process of installing the deis cli.

[meta] all components should report their 2.0.x version string

In Deis v1.x each component has an ENV DEIS_RELEASE v1.x string in its Dockerfile. That was a workaround that may no longer be needed, and requires lots of clerical PRs just to update strings. In Deis v2.x it would be preferable for each component to print its version up-front, on startup.

docs: Tell user to set the `--namespace=deis` flag

The most likely workflow for a new user will be that their namespace is set to be default. So we need to make sure that the install works fine even so.

That means we need to do:

$ helm install --namespace=deis deis/deis

(Alternate config instructions could suggest that they do this with kubectl itself)

Currently, the installation workflow will fail without the --namespace.

rewrite docs in markdown

We've already written the docs for helm using mkdocs and it's seeing success in both contribution and readability, so let's refactor the docs now while I'm already in the middle of re-writing half of it.

deis open opens http://<app name>.localhost in browser

After creating a cluster, registering a deis client, and doing a deis pull type deployment... when I run:

../workflow/client/deis create --no-remote
Creating Application... done, created calmer-handbill
remote available at ssh://git@deis.$IP.xip.io:2222/calmer-handbill.git
 ~/go/src/github.com/deis/example-go  ⑂ master    ../workflow/client/deis pull deis/example-go -a calmer-handbill
Creating build... done
 ~/go/src/github.com/deis/example-go  ⑂ master    ../workflow/client/deis open -a calmer-handbill

My browser opens with the URL: http://calmer-handbill.localhost/

It should open to http://calmer-handbill.$IP.xip.io/

`PullImageError` on app pods

I created an app with a git push, and the launched pod (and later pods launched by subsequent git pushes) go into PullImageError state:

ENG000656:workflow aaronschlesinger$ k get --namespace=wicker-radiator pod
NAME                           READY     STATUS           RESTARTS   AGE
wicker-radiator-v3-web-au7sn   0/1       PullImageError   0          1h
wicker-radiator-v4-web-uc4gz   0/1       PullImageError   0          1h
wicker-radiator-v5-web-iikid   0/1       PullImageError   0          28m
ENG000656:workflow aaronschlesinger$ k describe --namespace=wicker-radiator pod wicker-radiator-v5-web-iikid
Name:               wicker-radiator-v5-web-iikid
Namespace:          wicker-radiator
Image(s):           10.3.0.185:5000/wicker-radiator:v5
Node:               172.17.8.100/172.17.8.100
Start Time:         Wed, 16 Dec 2015 12:48:54 -0800
Labels:             app=wicker-radiator,heritage=deis,type=web,version=v5
Status:             Pending
Reason:             
Message:            
IP:             10.2.76.250
Replication Controllers:    wicker-radiator-v5-web (1/1 replicas created)
Containers:
  wicker-radiator-web:
    Container ID:   
    Image:      10.3.0.185:5000/wicker-radiator:v5
    Image ID:       
    State:      Waiting
      Reason:       PullImageError
    Ready:      False
    Restart Count:  0
    Environment Variables:
Conditions:
  Type      Status
  Ready     False 
Volumes:
  default-token-m3h32:
    Type:   Secret (a secret that should populate this volume)
    SecretName: default-token-m3h32
Events:
  FirstSeen LastSeen    Count   From            SubobjectPath               Reason      Message
  ─────────   ────────    ───── ────            ─────────────             ──────      ───────
  28m       28m     1   {scheduler }                            Scheduled   Successfully assigned wicker-radiator-v5-web-iikid to 172.17.8.100
  28m       28m     1   {kubelet 172.17.8.100}  implicitly required container POD   Pulled      Container image "gcr.io/google_containers/pause:0.8.0" already present on machine
  28m       28m     1   {kubelet 172.17.8.100}  implicitly required container POD   Created     Created with docker id cf80574d2123
  28m       28m     1   {kubelet 172.17.8.100}  implicitly required container POD   Started     Started with docker id cf80574d2123
  28m       1s      174 {kubelet 172.17.8.100}  spec.containers{wicker-radiator-web}    Pulling     Pulling image "10.3.0.185:5000/wicker-radiator:v5"
  28m       1s      174 {kubelet 172.17.8.100}  spec.containers{wicker-radiator-web}    Failed      Failed to pull image "10.3.0.185:5000/wicker-radiator:v5": API error (500): invalid registry endpoint https://10.3.0.185:5000/v0/: unable to ping registry endpoint https://10.3.0.185:5000/v0/
v2 ping attempt failed with error: Get https://10.3.0.185:5000/v2/: tls: oversized record received with length 20527
 v1 ping attempt failed with error: Get https://10.3.0.185:5000/v1/_ping: tls: oversized record received with length 20527. If this private registry supports only HTTP or HTTPS with an unknown CA certificate, please add `--insecure-registry 10.3.0.185:5000` to the daemon's arguments. In the case of HTTPS, if you have access to the registry's CA certificate, no need for the flag; simply place the CA certificate at /etc/docker/certs.d/10.3.0.185:5000/ca.crt

It looks like a registry issue, possibly related to #99 because the logs therein indicate there may be registry issues also.

k8s.py creates a service with a randomized name for the app

After deploying an app:

[vagrant@kubernetes-minion-1 ~]$ deis pull deis/example-go -a lively-dragster
Creating build... done

I see that the RC was named properly, but not the service:

><> k get rc --namespace=lively-dragster
CONTROLLER               CONTAINER(S)          IMAGE(S)                                 SELECTOR                                   REPLICAS
lively-dragster-v2-cmd   lively-dragster-cmd   10.247.252.167:5000/lively-dragster:v2   name=lively-dragster,type=cmd,version=v2   1
><> k get svc --namespace=lively-dragster
NAME       LABELS                 SELECTOR                        IP(S)          PORT(S)
app-7216   name=lively-dragster   name=lively-dragster,type=cmd   10.247.84.53   80/TCP

We should have the service name as lively-dragster, or else other apps in the same namespace (once we introduce something like deis teams into the mix) won't be able to discover each other in a sane way. I'll write up a proposal so we can discuss what needs to change in order to have this work.

migrate client builds to bintray

Travis artifacts is great for creating builds and uploading to S3, but one thing it misses on is the ability to grab the "latest" build (as seen in the README). In order for a user to grab the latest client build, he or she must know the latest Travis build that went green and download the client using that URL.

@sgoings fronted the work with releasing the helm client on bintray which so far has been a great success, so perhaps we should move over to bintray for that one-liner (curl https://... | sh) special sauce.

Proposal: Change format of `/v1/apps/<app id>/run`

Currently run returns a dynamic array (Ewww!) [0, "hi\n"]. The original docs docs say that run should return {"rc": 0, "output": "hi"}, which seems much more sensible to me.

I would like to propose to change the response of run to the format suggested to the docs:

{
  "rc": <return code>, 
  "output": "<command output>"
}

This is a backwards incompatible change, so this would probably would require API version bump to version 2.

error in controller when scaling

When scaling an app from 1 to 3, I get this error message:

[vagrant@kubernetes-minion-1 ~]$ deis scale cmd=3 -a lively-dragster
Scaling processes... but first, coffee!
Error: 
503 SERVICE UNAVAILABLE
detail: Successfully assigned lively-dragster-v2-cmd-u2u1y to 10.245.1.3

And in the controller:

INFO lively-dragster: bacongobbler scaled containers cmd=3
INFO [lively-dragster]: bacongobbler scaled containers cmd=3
DEBUG scale lively-dragster_v2.cmd, img lively-dragster:v2, params {u'num': 3, u'tags': {}, u'aname': u'lively-dragster', u'version': u'v2', u'memory': {}, u'cpu': {}}, cmd ""
ERROR lively-dragster: lively-dragster_v2.cmd (scale): Successfully assigned lively-dragster-v2-cmd-u2u1y to 10.245.1.3
ERROR [lively-dragster]: lively-dragster_v2.cmd (scale): Successfully assigned lively-dragster-v2-cmd-u2u1y to 10.245.1.3
10.246.6.1 "POST /v1/apps/lively-dragster/scale/ HTTP/1.1" 503 77 "Deis Client v1.12.1"

My RC is still stuck at 1/1 instances, so the operation never went through. More digging into this error is required.

deis/workflow fails to start

Testing the deis chart as of this morning leads to deis/workflow restarting:

[2015-12-11 17:49:48 +0000] [151] [INFO] Booting worker with pid: 151
[2015-12-11 17:49:48 +0000] [152] [INFO] Booting worker with pid: 152
Publishing DB state to etcd...
Traceback (most recent call last):
  File "./manage.py", line 13, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/lib/python2.7/site-packages/django/core/management/__init__.py", line 399, in execute_from_command_line
    utility.execute()
  File "/usr/lib/python2.7/site-packages/django/core/management/__init__.py", line 392, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/lib/python2.7/site-packages/django/core/management/base.py", line 242, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/usr/lib/python2.7/site-packages/django/core/management/base.py", line 285, in execute
    output = self.handle(*args, **options)
  File "/app/api/management/commands/load_db_state_to_etcd.py", line 14, in handle
    for obj in model.objects.all():
  File "/usr/lib/python2.7/site-packages/django/db/models/query.py", line 96, in __iter__
    self._fetch_all()
  File "/usr/lib/python2.7/site-packages/django/db/models/query.py", line 857, in _fetch_all
    self._result_cache = list(self.iterator())
  File "/usr/lib/python2.7/site-packages/django/db/models/query.py", line 220, in iterator
    for row in compiler.results_iter():
  File "/usr/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 713, in results_iter
    for rows in self.execute_sql(MULTI):
  File "/usr/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 786, in execute_sql
    cursor.execute(sql, params)
  File "/usr/lib/python2.7/site-packages/django/db/backends/util.py", line 53, in execute
    return self.cursor.execute(sql, params)
  File "/usr/lib/python2.7/site-packages/django/db/utils.py", line 99, in __exit__
    six.reraise(dj_exc_type, dj_exc_value, traceback)
  File "/usr/lib/python2.7/site-packages/django/db/backends/util.py", line 53, in execute
    return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: relation "key" does not exist
LINE 1: ..., "key"."id", "key"."public", "key"."fingerprint" FROM "key"

`deis info` produces a 404 error

Using a client built last Friday (12/11/2015) from HEAD of master,

core@micro-kube ~/example-go $ ./deis --version
1.13.0-dev
core@micro-kube ~/example-go $ ./deis info
Error: 
404 NOT FOUND
detail: Not found

@bacongobbler since you have #71 open and it's marked under the v2.0-alpha1 milestone, I've marked this issue as such as well. I have't tested with a client uploaded by the CI setup in your PR, however.

If you can give me such a client, I'll re-test.

`deis destroy` generates 500 error

Testing Deis v2 alpha with a deis pull app gave me an error on deis destroy:

DEBUG destroy ribbed-asteroid_v2.cmd.1
ERROR ribbed-asteroid: aborting, failed to destroy some containers
ERROR [ribbed-asteroid]: aborting, failed to destroy some containers
WARNING ribbed-asteroid: Error deleting existing application logs: HTTPConnectionPool(host='127.0.0.1', port=8088): Max retries exceeded with url: /ribbed-asteroid/ (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f31af2e3350>: Failed to establish a new connection: [Errno 111] Connection refused',))
WARNING [ribbed-asteroid]: Error deleting existing application logs: HTTPConnectionPool(host='127.0.0.1', port=8088): Max retries exceeded with url: /ribbed-asteroid/ (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f31af2e3350>: Failed to establish a new connection: [Errno 111] Connection refused',))
ERROR Internal Server Error: /v2/apps/ribbed-asteroid/
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/django/core/handlers/base.py", line 112, in get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/usr/lib/python2.7/site-packages/django/views/decorators/csrf.py", line 57, in wrapped_view
    return view_func(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/rest_framework/viewsets.py", line 85, in view
    return self.dispatch(request, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/rest_framework/views.py", line 407, in dispatch
    response = self.handle_exception(exc)
  File "/usr/lib/python2.7/site-packages/rest_framework/views.py", line 404, in dispatch
    response = handler(request, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/rest_framework/mixins.py", line 85, in destroy
    self.perform_destroy(instance)
  File "/usr/lib/python2.7/site-packages/rest_framework/mixins.py", line 89, in perform_destroy
    instance.delete()
  File "/app/api/models.py", line 223, in delete
    return super(App, self).delete(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/django/db/models/base.py", line 695, in delete
    collector.delete()
  File "/usr/lib/python2.7/site-packages/django/db/models/deletion.py", line 282, in delete
    sender=model, instance=obj, using=self.using
  File "/usr/lib/python2.7/site-packages/django/dispatch/dispatcher.py", line 185, in send
    response = receiver(signal=self, sender=sender, **named)
  File "/app/api/models.py", line 1165, in _etcd_purge_config
    prevExist=True, dir=True, recursive=True)
  File "/usr/lib/python2.7/site-packages/etcd/client.py", line 389, in delete
    self.key_endpoint + key, self._MDELETE, params=kwds)
  File "/usr/lib/python2.7/site-packages/etcd/client.py", line 582, in api_execute
    return self._handle_server_response(response)
  File "/usr/lib/python2.7/site-packages/etcd/client.py", line 598, in _handle_server_response
    etcd.EtcdError.handle(**r)
  File "/usr/lib/python2.7/site-packages/etcd/__init__.py", line 142, in handle
    raise exc(msg)
Exception: Raft Internal Error : etcdserver: request timed out
10.246.43.1 "DELETE /v2/apps/ribbed-asteroid/ HTTP/1.1" 500 27 "Deis Client v1.13.0-dev"

kubectl shows that the Namespace (and therefore associated Services, RCs, and Pods) was actually deleted.

add more user-friendly docstring to TODO doc pieces

Most of the documentation under "Managing Deis" now have a placeholder that looks something like this. Instead, we should come up with a good docstring to explain to users of the alpha release that this is currently a work in progress for the beta and stable releases.

add mock k8s tests

Having some library to inspect the requests sent to kubernetes would be helpful for adding unit tests to new features in the kubernetes client. That way we aren't spending all of our time manually testing these features.

[added by @helgi]:
Minimum coverage needs to be 85% per file / class in the scheduler to be considered good coverage

Following need work:

  • __init__.py
  • Deployment
  • HPA
  • Pod
  • RC

https://codecov.io/gh/deis/controller/tree/master/rootfs/scheduler has the most up to date information

'deis pull' generates 500 error

the ultima-windmill app exists:

core@micro-kube ~/example-go $ ./deis apps
=== Apps
ultima-windmill

then, the deis pull fails:

core@micro-kube ~/example-go $ ./deis pull deis/example-go -a ultima-windmill
Creating build... Error: 
500 INTERNAL SERVER ERROR
<h1>Server Error (500)</h1>

Integrate app level configuration with k8s

Today there are two ways of affecting router configuration.  

We can separately consider global router configuration (things like are we or are we not using proxy protocol) and then router configuration that’s more at an app/vhost level.  

  • The former are configured using deisctl config set router foo=bar.
  • The latter are derived from each application’s model.

The former requires no action for v2. If someone wants to modify global router configuration, they can directly edit the router RC’s manifest.

What we need is for all necessary information about an application, for instance (but not limited to) custom domains, certs, or a flag indicating e2e https on/off, get mapped to appropriate k8s constructs

In most cases, that means adding/updating annotations on an app’s service and the router will read those. In other cases, it might involve something slightly more complex like managing certs as k8s secrets (secrets will be in scope for beta).

Ultimately, what this means is that how the router fulfills requests initiated from the likes of deis domains:add www.example.com or deis certs:add server.crt server.key will have to change.

replace application health checks with kubernetes rc health checks

The original intent of app health checks was to ensure that we could easily "plug and play" with kubernetes' health check system for replication controllers. Now that deis/publisher no longer exists, we don't have any "readiness" checks to remove an instance from the routing table if it becomes unavailable. We'll need to revamp the system and rebase it on top of kubernetes.

deis pull results in 502 Bad Gateway

I created a deis app:

 ~/go/src/github.com/deis/example-dockerfile-http  ⑂ master    ../workflow/client/deis create
Creating Application... done, created frozen-fishbone
Git remote deis added
remote available at ssh://[email protected]:2222/frozen-fishbone.git

Then did a deis pull:

 ~/go/src/github.com/deis/example-dockerfile-http  ⑂ master    ../workflow/client/deis pull tomcat
Creating build... done

The service, rc, and pod are running:

 ~/go/src/github.com/deis/example-dockerfile-http  ⑂ master    k get rc,po,svc --namespace=frozen-fishbone
CONTROLLER               CONTAINER(S)          IMAGE(S)                                SELECTOR                                                REPLICAS   AGE
frozen-fishbone-v2-cmd   frozen-fishbone-cmd   10.255.245.20:5000/frozen-fishbone:v2   app=frozen-fishbone,heritage=deis,type=cmd,version=v2   1          7m
NAME                           READY     STATUS    RESTARTS   AGE
frozen-fishbone-v2-cmd-z1e05   1/1       Running   0          6m
NAME              CLUSTER_IP      EXTERNAL_IP   PORT(S)   SELECTOR                                     AGE
frozen-fishbone   10.255.250.23   <none>        80/TCP    app=frozen-fishbone,heritage=deis,type=cmd   6m

When I curl the address:

~/go/src/github.com/deis/example-dockerfile-http  ⑂ master    curl -v frozen-fishbone.104.197.67.227.xip.io
* Rebuilt URL to: frozen-fishbone.104.197.67.227.xip.io/
*   Trying 104.197.67.227...
* Connected to frozen-fishbone.104.197.67.227.xip.io (127.0.0.1) port 80 (#0)
> GET / HTTP/1.1
> Host: frozen-fishbone.104.197.67.227.xip.io
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 502 Bad Gateway
< Server: nginx/1.9.6
< Date: Wed, 16 Dec 2015 23:01:50 GMT
< Content-Type: text/html
< Content-Length: 172
< Connection: keep-alive
<
<html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
<hr><center>nginx/1.9.6</center>
</body>
</html>
* Connection #0 to host frozen-fishbone.104.197.67.227.xip.io left intact

The related nginx config.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.