[{"_1":2,"_154":-5,"_155":-5},"loaderData",{"_3":4,"_13":14,"_21":22,"_133":134},"root",{"_5":-5,"_6":-7,"_7":8,"_9":-7,"_10":11,"_12":-7},"currentUser","primaryEmail","siteVerification","6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI","toast","enableDev",false,"incidentStatus","routes/_layout",{"_15":-5,"_16":17,"_18":17,"_19":11,"_20":11},"username","isAskGordonEnabled",true,"isUsingNewTemplate","showMinimalLanding","showHoneypotTrap","routes/_layout.r.$namespace.$reponame",{"_23":24,"_25":-5,"_26":11,"_27":11,"_28":29,"_30":29,"_31":-5,"_32":11,"_33":34,"_83":-5,"_84":85,"_124":-5,"_125":11,"_126":17,"_127":11,"_128":-5,"_129":11,"_130":-5,"_131":132},"canonicalUrl","https://hub.docker.com/r/yemenlinux/yemenlinux/tags","mcpServer","canSeeDockerfile","canSeeAutobuilds","namespace","yemenlinux","reponame","cloudBuildSource","isAutobuildsAvailable","repo",{"_35":36,"_37":38,"_40":41,"_42":43,"_44":11,"_45":46,"_47":48,"_49":50,"_52":29,"_28":29,"_53":54,"_55":39,"_56":57,"_58":59,"_60":61,"_62":-5,"_63":57,"_64":65,"_66":11,"_67":29,"_68":69,"_74":11,"_75":76,"_80":29,"_81":82},"categories",[],"content_types",[39],"image","date_registered","2019-06-08T16:57:34.059403Z","description","YemenLinux Repository ","is_private","last_updated","2019-06-21T18:25:06.079626Z","last_modified","2024-10-16T13:48:34.145251Z","media_types",[51],"application/vnd.docker.container.image.v1+json","name","pull_count",849,"repository_type","star_count",0,"status",1,"status_description","active","source","collaborator_count","full_description","\n# Clearwater Docker\n\nThis repository contains instructions and resources for deploying [Project Clearwater](http://www.projectclearwater.org) as [Docker](https://www.docker.com/) containers. It describes three deployment options -- the first two are recommended.\n\n- Using [Docker Compose](https://docs.docker.com/compose/) for quick deployments on a single host.\n- Using [Kubernetes](https://kubernetes.io/) for orchestrated deployments on clusters of machines.\n- By deploying the containers manually.\n\nYou should follow the \"Common Preparation\" section, then either the \"Using Compose\", \"Using Kubernetes\" or the \"Manual Turn-Up\" section.\n\n## Common Preparation\n\nWhen using the `3.13.0-74-generic` kernel, we've seen [an issue](https://github.com/Metaswitch/clearwater-docker/issues/24) which causes Clearwater not to start properly. If you are using this kernel (`uname -r` will tell you), you should install a newer kernel (e.g. with `sudo apt-get install linux-image-3.13.0-87-generic`) and reboot.\n\nTo prepare your system to deploy Clearwater on Docker, run:\n\n # Install Docker (on Ubuntu).\n wget -qO- https://get.docker.com/ | sh\n\n # Checkout clearwater-docker.\n # Either:\n git clone --recursive git@github.com:Metaswitch/clearwater-docker.git\n # Or:\n git clone --recursive https://github.com/Metaswitch/clearwater-docker.git\n\nIf deploying with compose or manually\n- edit clearwater-docker/.env so that PUBLIC_IP is set to an IP address that can be used by SIP clients to access the docker host. E.g. if you are running in AWS, this wants to be the public IP of your AWS VM. Note: this file is not used when deploying on Kubernetes.\n- if you want to be able to monitor your Docker deployment via a web UI then you might like to install and run [Weave Scope](https://www.weave.works/products/weave-scope/). This only takes a minute to [install](https://www.weave.works/install-weave-scope/) and provides real time visualizations showing all of your containers, their resource usage and the connectivity between them.\n\nBy default Docker images built using clearwater-docker will pull the latest stable versions of Clearwater packages from http://repo.cw-ngv.com/stable. If you check out the latest stable branch of clearwater-docker e.g. release-XXX then this should be fine. If you are using the master branch of clearwater-docker then it will sometimes be dependent upon the latest Clearwater packages. To use these instead update base/Dockerfile to reference http://repo.cw-ngv.com/latest instead before building the base Docker image.\n\n![alt text](docs/images/clearwater-docker_in_scope.jpg \"Clearwater-Docker dispayed in Scope\")\n\n## Limitations\n\nNote that scaling of Docker deployments is a work in progress and there are currently a number of known issues...\n\n* Homestead-prov and Ellis don’t load balance across multiple Cassandra nodes.\n\n* In general deleting pods from storage clusters (Cassandra, Chronos or Astaire) is not supported. Pods that are deleted will not get removed from the clusters and the clusters will end up broken. The exception is when deployed under Kubernetes -- in this scenario Chronos and Astaire pods can be terminated, so long as this is done gracefully such that their prestop event hook is executed. This means that Astaire and Chronos clusters (under Kubernetes) can be dynamcially scaled up and down.\n\n## Using Compose\n\nThere is a [Compose file](minimal-distributed.yaml) to instantiate a minimal (non-fault-tolerant) distributed Clearwater deployment under Docker.\n - 104.155.15.20\n\n#### Preparation\n\nTo prepare your system to deploy Clearwater using Compose, after running the common preparation steps above, run:\n\n # Install Docker Compose (on Ubuntu).\n sudo apt-get install python-pip -y\n sudo pip install -U docker-compose\n\n # Build the base Clearwater docker image.\n cd clearwater-docker\n sudo docker build -t clearwater/base base\n sudo docker-compose -f minimal-distributed.yaml build\n\nNote that Compose will name each image like `${IMAGE_PREFIX}/` and `IMAGE_PREFIX=clearwater` by default. If you need to specify your registry, please edit `IMAGE_PREFIX` in `clearwater-docker/.env` like `IMAGE_PREFIX=/clearwater`.\n\n#### Starting Clearwater\n\nTo start the Clearwater services, run:\n\n # Build all the other Clearwater Docker images and start a deployment.\n sudo docker-compose -f minimal-distributed.yaml up -d\n\n#### Scaling the deployment\n\nHaving started up a deployment, it is then possible to scale it by adding or removing additional nodes. E.g. run\n\n sudo docker-compose -f minimal-distributed.yaml scale sprout=2 astaire=2 chronos=2 cassandra=2\n\nNote that it is not possible to scale *down* storage node clusters -- see limitations above.\n\nIf you scale *up* the clusters of storage nodes, you can monitor progress as new nodes join the clusters by running `utils/show_cluster_state.sh`.\n\n## Using Kubernetes\n\nInstead of using Docker Compose, you can deploy Clearwater in Kubernetes. This requires a Kubernetes cluster, and a Docker repository.\n\n### Prepare the images and edit the yaml files\n\n- First, build all the required images locally.\n\n # Build the Clearwater docker images.\n cd clearwater-docker\n for i in base astaire cassandra chronos bono ellis homer homestead homestead-prov ralf sprout ; do docker build -t clearwater/$i $i ; done\n\n- Next, push them to your repository (which must be accessible from the Kubernetes deployment)\n\n for i in base astaire cassandra chronos bono ellis homer homestead homestead-prov ralf sprout\n do\n docker tag clearwater/$i:latest path_to_your_repo/clearwater/$i:latest\n docker push path_to_your_repo/clearwater/$i:latest\n done\n\n- Create an `env-vars` config map.\n - At a minimum this must include a ZONE key set to the domain of your Kubernetes cluster e.g. `default.svc.cluster.local`\n - If you wish to use an HSS (instead of Ellis and Homestead-prov) then you can also include an HSS key with a value equal to the name of the HSS node: this will result in the deployment being configured to use the HSS at `.`, with an HSS realm of ``. If you want to use an HSS in a different domain then you will have to manually configure the appropriate values -- see below.\n - It may also include an ADDITIONAL_SHARED_CONFIG key whose value includes additional shared config settings that you want to use. These will override any auto-generated settings. E.g. this can be used to specify an HSS in a different domain. Multiple settings should be separated with `\\\\n`\n\n e.g. `kubectl create configmap env-vars --from-literal=ZONE=default.svc.cluster.local --from-literal=ADDITIONAL_SHARED_CONFIG=hss_hostname=hss.example.com\\\\nhss_realm=example.com`\n\n- If you're using a private container registry (one that requires credentials to pull images from), create a secret with the required credentials. e.g. `kubectl create secret docker-registry myregistrykey --docker-server=$DOCKER_REGISTRY_SERVER --docker-username=$DOCKER_USER --docker-password=$DOCKER_PASSWORD --docker-email=$DOCKER_EMAIL`\n- Update the Kubernetes yaml to match your deployment.\n\n - Generate the Kubernetes yaml files from the templates by going to the kubernetes directory and running `./k8s-gencfg --image_path= --image_tag=`\n If you're using a private container registry, add the argument `--image_secret=myregistrykey` (where `myregistrykey` matches the secret you made earlier)\n The script assumes that the Clearwater images that you want to use are located at {{image_path}}/\\:{{image_tag}}. It will also generate a helm chart in `/kubernetes/clearwater`.\n\n - Decide how you want to access Bono and Ellis from outside of the cluster.\n\n The default configuration assumes that you have configured your network such that your SIP endpoints (and whatever devices you will access Ellis from) can\n - connect directly to the IP addresses that Kubernetes assigns to your pods\n - resolve interal kubernetes DNS records (typically as a result of an external DNS server delegating requests for the appropriate domain to the Kubernetes DNS service)\n\n If this is the case then you do not need to make any changes here. SIP devices can register with bono.:5060 and the Ellis provisioning interface can be accessed at http://ellis.. If these requirements are not met then you will need to arrange alternative means to access Bono and Ellis -- see below for an example of how this can be done on e.g. GKE.\n\n#### Alternative configuration for exposing Bono and Ellis services\n\nIf the above requirements are not met (external devices cannot resolve Kubernetes DNS entries and/or cannot directly access pod IP addresses) then an alternative mechanism must be used to access Ellis and Bono.\n\n - To expose Ellis, you can simply set it up as a NodePort service:\n - Replace `clusterIP: None` in ellis-svc.yaml with `type: NodePort`, and add a line to the \"http\" port configuration specifying `nodePort: `\n - Depending on your platform you may need to manually create a firewall rule to allow access to this port. E.g. on GKE this can be done from the command line using gcloud if you have it installed. e.g.\n `gcloud compute firewall-rules create ellis --allow tcp:30080`\n - The Ellis provisioning interface can then be accessed on http::30080\n - If you are unable to access the Ellis web interface (e.g. this happens with [AKS](https://docs.microsoft.com/en-us/azure/aks/)) then you should instead replace `clusterIP: None` with `type: LoadBalancer`.\n\n - Bono is more challenging to expose due to the following requirements:\n - Each Bono pod must be configured with an externally routable IP address by which that specific pod can be uniquely accessed. Bono will record-route itself in SIP messages using this IP and susbequent SIP messages to that IP address must be guaranteed to hit the same Bono instance.\n - Port 5060 in the Bono pod must be accessible via port 5060 on the external IP address. It is not possible to e.g. NAT port 5060 in the pod to port 30060 on the external IP. This is because Bono always record-route's itself in SIP messages as :5060.\n\n On e.g. [GKE](https://cloud.google.com/kubernetes-engine/) the easiest solution is to use a LoadBalancer with a statically assigned external IP address. This brings in the following limitations:\n - you can only have a single Bono instance (as subsequent SIP requests in a session must be guaranteed to be routed back to the same Bono instance so you cannot have the load balancer balance across multiple Bonos)\n - the deployment can only support SIP over UDP or SIP over TCP (not both simultaneously) as Bono cannot have separate external IP addresses for each of UDP and TCP, and a single Kubernetes LoadBalancer service can't support multiple protocols. By default bono-svc.yaml is configured to expose SIP over TCP.\n\n If using [AKS](https://docs.microsoft.com/en-us/azure/aks/)\n - You must disable [HTTP Application routing](https://docs.microsoft.com/en-us/azure/aks/http-application-routing) when creating the cluster\n - you must replace `clusterIP: None` with `type: LoadBalancer` in `bono-svc.yaml`.\n\n For GKE and other platforms you must:\n - Have a static external IP address available that the load balancer can use (e.g. on GKE you must explicitly provision this first)\n - Replace `clusterIP: None` in bono-svc.yaml with `type: \"LoadBalancer\"`, and add a line following this of `loadBalancerIP: `\n - Add the lines `name: PUBLIC_IP` and `value: ` to the `env:` section of the bono-depl.yaml file\n\n### Deploy Clearwater in Kubernetes\n\n#### Using kubectl\n\nTo deploy the images, you should simply run `kubectl apply -f clearwater-docker/kubernetes`. It may take a minute or so before the deployment is fully established, the load balancer is created, and the deployment is ready to accept calls.\n\nNote this will deploy all containers. If you don't need e.g. Bono, Homestead-prov, Ellis etc. then just move the corresponding svc and depl files out of the directory before running the create command.\n\n#### Using helm\n\nRun `helm install clearwater` inside `kubernetes` directory to deploy.\n\n### Run live tests against the deployment\n\nIf you have deployed using the standard configuration then you can run the [clearwater-live-tests](https://github.com/Metaswitch/clearwater-live-test/) against the deployment using e.g.\n\n```\nrake test[default.svc.cluster.local] PROXY=\"bono.default.svc.cluster.local\" SIGNUP_CODE=secret\n```\n\nIf you have had to expose Bono and Ellis in a non-standard manner, you may need to change the `PROXY` argument, and add an `ELLIS` argument, so that the test scripts are able to access these services. e.g.\n\n```\nrake test[default.svc.cluster.local] PROXY={{Bono service DNS/IP}} ELLIS={{Ellis service/IP}} SIGNUP_CODE=secret\n```\n\n### Scaling the deployment\n\nMost Clearwater services can be dynamically scaled up and down by running e.g.\n`kubectl scale deployment sprout --replicas=3`\nExceptions are:\n- You can only have a single Bono if Bono pods do not have externally routable IP addresses.\n- Astaire and Chronos clusters can be scaled up and down so long as pods are terminated in such a way that their prestop hook is executed.\n- The Cassandra cluster can be scaled up but not down.\nSee general limitations above.\n\nAfter scaling the Chronos, Astaire or Cassandra clusters you should wait for the clusters to stabilise before performing another scaling operation. You can monitor cluster state by running cw-check_cluster_state in a pod belonging to any of the clusters.\n\n## Manual Turn-Up\n\nIf you can't or don't want to use Compose, you can turn the deployment up manually under Docker.\n\n#### Preparation\n\nTo prepare your system to deploy Clearwater without using Compose, after running the common preparation steps above, run:\n\n # Build the Clearwater docker images.\n cd clearwater-docker\n for i in base astaire cassandra chronos bono ellis homer homestead homestead-prov ralf sprout ; do sudo docker build -t clearwater/$i $i ; done\n\n#### Starting Clearwater\n\nTo start the Clearwater services, run:\n\n sudo docker network create --driver bridge clearwater_nw\n sudo docker run -d --net=clearwater_nw --name etcd quay.io/coreos/etcd:v2.2.5 -name etcd0 -advertise-client-urls http://etcd:2379,http://etcd:4001 -listen-client-urls http://0.0.0.0:2379,http://0.0.0.0:4001 -initial-advertise-peer-urls http://etcd:2380 -listen-peer-urls http://0.0.0.0:2380 -initial-cluster etcd0=http://etcd:2380 -initial-cluster-state new\n sudo docker run -d --net=clearwater_nw --name astaire -p 22 clearwater/astaire\n sudo docker run -d --net=clearwater_nw --name cassandra -p 22 --sysctl net.ipv6.conf.lo.disable_ipv6=0 clearwater/cassandra\n sudo docker run -d --net=clearwater_nw --name chronos -p 22 clearwater/chronos\n sudo docker run -d --net=clearwater_nw --name homestead -p 22 clearwater/homestead\n sudo docker run -d --net=clearwater_nw --name homestead-prov -p 22 clearwater/homestead-prov\n sudo docker run -d --net=clearwater_nw --name homer -p 22 clearwater/homer\n sudo docker run -d --net=clearwater_nw --name ralf -p 22 clearwater/ralf\n sudo docker run -d --net=clearwater_nw --network-alias=icscf.sprout --network-alias=scscf.sprout --name sprout -p 22 clearwater/sprout\n sudo docker run -d --net=clearwater_nw --name bono --env-file .env -p 22 -p 3478:3478 -p 3478:3478/udp -p 5060:5060 -p 5060:5060/udp -p 5062:5062 clearwater/bono\n sudo docker run -d --net=clearwater_nw --name ellis -p 22 -p 80:80 clearwater/ellis\n\nThe Clearwater Docker images use DNS for service discovery - they require, for example, that the name \"ellis\" should resolve to the Ellis container's IP address. In standard Docker, user-defined networks include [an embedded DNS server](https://docs.docker.com/engine/userguide/networking/dockernetworks/#docker-embedded-dns-server) which guarantees this (and this is why we create the clearwater_nw network) - and this type of DNS server is relatively common (for example, [Kubernetes provides something similar](http://kubernetes.io/docs/user-guide/services/#dns)).\n\n#### Scaling the deployment\n\nIt is possible to spin up additional Sprout, Cassandra, Astaire and Chronos nodes simply by repeating the relevant command `docker run` command but providing a different name. E.g.\n\n sudo docker run -d --net=clearwater_nw --name astaire_2 -p 22 clearwater/astaire\n\nScaling of clearwater-docker deployments is work in progress though, so see the limitations described above (for scaling using Compose).\n\n## Exposed Services\n\nThe deployment exposes\n\n- the Ellis web UI on port 80 (exposed on port 8080) for self-provisioning - the signup key is \"secret\"\n- STUN/TURN on port 3478 for media relay\n- SIP on port 5060 for service\n- SIP/WebSocket on port 5062 for service.\n\nAdditionally, each node exposes SSH - use `sudo docker ps` to see what port its exposed on. The username/password is root/root. Alternatively you can run a bash session in a container by name using e.g. `sudo docker exec -it bash`\n\n## What Next?\n\nOnce you've turned up the deployment, you can test it by\n\n- [making a call](http://clearwater.readthedocs.org/en/latest/Making_your_first_call.html) - make sure you configure your SIP clients with a proxy, as if it were an All-in-One node\n- [running the live tests](http://clearwater.readthedocs.org/en/latest/Running_the_live_tests.html) - again, set the PROXY and ELLIS elements, as if it were an All-in-One node.\n\n## Utilities\n\nThere are a few scripts that offer short cuts to querying aspects of your deployment:\n\n # Show an abbreviated version of docker ps that fits without wrapping on smaller terminals\n utils/short_ps.sh\n\n # Show the IP addresses of the containers in your deployment\n utils/show_ips.sh\n\n # Query Chronos nodes over SNMP to get the number of active registrations\n utils/show_registration_count.sh\n\n # Show information about the state of the storage clusters\n utils/show_cluster_state.sh\n\nIf one of your pods is failing and you can't `exec` into it because it's in a crash loop, just run `kubectl logs` on the sidecar instead. e.g.\n\n kubectl logs astaire-7b74ff8df9-5lhz6 -c tailer\n\n## Cleaning Up\n\nIf you wish to destroy your deployment either to redeploy with a different configuration or version or to free up resources on your docker host, the following may be useful commands:\n\n # To rebuild an image (rather than pull it from the cache), add `--no-cache` or `--force-recreate` to the build commands\n sudo docker build --no-cache -t clearwater/base base\n sudo docker-compose -f minimal-distributed.yaml build\n sudo docker-compose -f minimal-distributed.yaml up --force-recreate\n\n # Remove all docker containers (not just Clearwater ones!)\n sudo docker rm $(sudo docker ps -aq)\n\n # Remove all the docker image files (not just Clearwater ones!)\n sudo docker rmi $(sudo docker images -aq)\n\n # Remove most of the docker image files, but not the Ubuntu 14.04 base\n # image, use this if you intend to redeploy the clearwater deployment\n # immediately to save time.\n #\n # This command will report an error due to a conflict, this can be safely\n # ignored.\n sudo docker rmi $(sudo docker images -a | tail -n +2 | grep -v \"14.04\" | tr -s ' ' | cut -f3 -d' ')\n","has_starred","hub_user","immutable_tags_settings",{"_70":11,"_71":72},"enabled","rules",[73],".*","is_automated","permissions",{"_77":17,"_78":11,"_79":11},"read","write","admin","user","storage_size",258635068,"orgData","recentTags",[86],{"_87":39,"_88":89,"_90":91,"_92":93,"_94":95,"_45":113,"_114":89,"_115":29,"_116":51,"_52":117,"_118":119,"_120":104,"_121":113,"_122":61,"_123":17},"content_type","creator",1176122,"full_size",258618762,"id",59709095,"images",[96],{"_97":98,"_99":100,"_101":102,"_103":104,"_105":106,"_107":108,"_109":102,"_110":-5,"_111":91,"_58":61,"_112":-5},"architecture","amd64","digest","sha256:6e8249e27afc76201d0942bd6bde3d07350bb7c7ba73dbde1dfbf04fc431c6a2","features","","last_pulled","2026-09-23T14:22:32.30579392Z","last_pushed","2019-06-21T18:25:06Z","os","linux","os_features","os_version","size","variant","2019-06-21T18:25:05.64325Z","last_updater","last_updater_username","media_type","latest","repository",7235977,"tag_last_pulled","tag_last_pushed","tag_status","v2","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","showSbxLogoOverride","sbxTrademarkText","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"routes/_layout.r.$namespace.$reponame.tags",{"_33":135,"_142":143,"_131":152,"_153":11},{"_35":136,"_37":137,"_40":41,"_42":43,"_44":11,"_45":46,"_47":48,"_49":138,"_52":29,"_28":29,"_53":54,"_55":39,"_56":57,"_58":59,"_60":61,"_62":-5,"_63":57,"_64":65,"_66":11,"_67":29,"_68":139,"_74":11,"_75":141,"_80":29,"_81":82},[],[39],[51],{"_70":11,"_71":140},[73],{"_77":17,"_78":11,"_79":11},"tags",{"_144":59,"_145":-5,"_146":-5,"_147":148},"count","next","previous","results",[149],{"_87":39,"_88":89,"_90":91,"_92":93,"_94":150,"_45":113,"_114":89,"_115":29,"_116":51,"_52":117,"_118":119,"_120":104,"_121":113,"_122":61,"_123":17},[151],{"_97":98,"_99":100,"_101":102,"_103":104,"_105":106,"_107":108,"_109":102,"_110":-5,"_111":91,"_58":61,"_112":-5},[],"canDeleteTags","actionData","errors"]

yemenlinux/yemenlinux

Tags for yemenlinux/yemenlinux