{"id":17040986,"url":"https://github.com/uggla/cloud_native_app","last_synced_at":"2025-06-22T05:02:39.802Z","repository":{"id":75443970,"uuid":"103528580","full_name":"uggla/cloud_native_app","owner":"uggla","description":"Simple Cloud Native Application used for demontration or training purpose","archived":false,"fork":false,"pushed_at":"2023-08-21T00:28:55.000Z","size":27190,"stargazers_count":1,"open_issues_count":1,"forks_count":12,"subscribers_count":5,"default_branch":"master","last_synced_at":"2025-06-20T12:59:25.949Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/uggla.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2017-09-14T12:19:54.000Z","updated_at":"2020-04-27T06:12:47.000Z","dependencies_parsed_at":"2024-10-14T09:11:08.441Z","dependency_job_id":"2090ae97-7097-45ab-b849-5df9a2be3f3a","html_url":"https://github.com/uggla/cloud_native_app","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/uggla/cloud_native_app","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/uggla%2Fcloud_native_app","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/uggla%2Fcloud_native_app/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/uggla%2Fcloud_native_app/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/uggla%2Fcloud_native_app/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/uggla","download_url":"https://codeload.github.com/uggla/cloud_native_app/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/uggla%2Fcloud_native_app/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":261238886,"owners_count":23128876,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-10-14T09:11:02.888Z","updated_at":"2025-06-22T05:02:34.788Z","avatar_url":"https://github.com/uggla.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"Cloud Native Application\n========================\n\nThis document purpose is to describe the Cloud Native Application training described below and which is in particular delivered to ENSIMAG IS students in 2017 and 2018.\n\nDocument writers:\n\n * Bruno.Cornec@hpe.com\n * Christophe.Larsonneur@dxc.com\n * Vincent.Misson@hpe.com\n * Rene.Ribaud@gmail.com\n\n# Overview of the Assessment\n\n## Objectives\n\nThe goal of this document is to describe the use case that will be used\nfor the training of ENSIMAG students\n\n## Reference documents\n\nThe main OpenStack entry point is at http://www.openstack.org\n\n * v1.0:\t2016-09-29 - First version\n * v1.1:\t2016-11-28 - Update with grade per part\n * v1.2:\t2017-01-16 - Update with evaluation method\n * v2.0:\t2017-09-25 - More focus on the DevOps life-cycle\n * v2.1:\t2017-10-20 - Review to match 2017 expectations\n\n# Project Story\n\nYou are in a company which achieved an aggressive deal with a Customer\nto leverage an open source cloud native application and use it internally\nfor their customers.\n\nWith a new team, you are in charge to deliver and maintain\nthe application in production in your new customer environment.\n\nThe customer gave you 4 major objectives:\n - The application is an open source cloud native application:\n    lottery for an e-commerce site\n - The customer requires the production environment to be Openstack cloud based.\n     The customer won't install or maintain it. This will be one of your tasks.\n - Any feature/bug request must be in production quickly, with control \u0026\n    quality.\n - You will have 7 weeks to deliver the application on the customer Hardware.\n   Before that date, the environment won't be considered as production\n   and can be re-built from scratch, anytime. Just contact the customer\n   to do it.\n\nThe Customer will give you 2 servers pre-installed with CentOS 7, to deliver\nthe application in production.\n\nYour company gives you an access to a reference OpenStack setup hosting a tenant\nto develop your environment (factory).\n\n## Objectives\n\nThe goal of this training is to build a software factory to do:\n- Continuous Improvement\n- Continuous Testing\n- Continuous Integration\n- Continuous Deployment of a cloud native application\n\nCo-related goals are:\n- Ensure security\n- Improve team work\n\n\n## Goals \u0026 constraints\n\n### Goals\n\nTo answer to customer need, your team choose to use the **DevOps**\nmethod/approach/best practices to deploy and maintain this application\nin production in the customer company HW.\n\nAs a consequence, practitioners will first have to:\n * Organize the team to work using DevOps best practices.\n * Automate the management of a virtual infrastructure (Infrastructure\n    as code concept). Your customer requires the use/usage of Openstack as\n    an Infrastructure as a Service platform (IaaS)\n * Define and implement a CICD pipeline to easily test and deploy the\n    application to a staging area then to production.\n * Put in place tooling to share/track application changes between team\n    members/customers.\n * Ensure correct level of security within the factory. (no private keys\n    or data available publicly, user access restriction, ports filtering...)\n\n### Constraints\n * Application should only expose http\\[s] (ports 80 and 443) to the external network.\n * All materials should be kept on public git repository (github, gitlab,\n    framasoft e.g.) with an Open Source license (Cf: https://opensource.org/licenses\n    prefer the popular ones). Please note that your git history should\n    reflect changes to the factory/infrastructure/application. Also, you\n    should commit properly with your personal credentials (email\n    preferred) with a unique account.\n * There is no restriction regarding the tools to implement the pipeline.\n  It could be external services and/or on premise tools. However, be\n  prepared to justify some choices.\n\n## Bonus goals\n * Put in place monitoring to ensure applications are working as expected.\n * Put in place name resolution.\n * Improve applications.\n * Optimize testing duration.\n * Communication dashboard about applications health to users.\n * Performance improvement of your application by scaling services.\n * Applications reliability.\n * Contribute back to the Open Source project\n\n# Application information\n\n## Application schema\n![application schema](schema/archi_docker.png)\n\n\n## Application description\n\n * 1 Web + reverse proxy provides a page with 5 visible parts/micro-services: I, S, B, W and P.\n * I(dentification) service: receives http request from customer (link with customer ID) and look for it into DB.\n * S(tatus) service: detect whether customer already played or not, status stored in the DB.\n * B(utton) service: button widget allowing the customer to play. Only when not already done.\n * W(orker) service that computes whether the customer won or not, called by B. If won, post an image representing what has been won into OpenStack Swift or Redis with customer ID. Then post by e-mail via an external provider a message to admins using a message bus. This service is povided by a 3rd party, so it can not be changed. As this service is really slow, scaling it should be considered.\n * P(icture) service: Look into Swift or Redis with customer ID to display the image of the customer, empty if no image.\n * Redis or Swift can be used to store data.\n * Rabbitmq is used to pass message from service B to service W1 and W2.\n * W1 services that listen on the messaging bus and write to the database.\n * W2 services that listen on the messaging bus and send http requests to mailgun external services.\n\n## Application materials (code, doc etc...)\nHere is the url of the Open Source project:\nhttps://github.com/uggla/cloud_native_app\n\n\n## Deliverables\n\n * On Github:\n   * Pipeline design documents and code\n   * Application code\n   * Infrastructure code (Heat template/ansible playbooks/scripts).\n\n * Your software factory should be ready to deliver a patch or a feature\n    requested by your customer.\n    This delivery will be in production during the exam.\n    The feature or fix requested can come from the upstream Open Source\n    project.\n\n * As a backup, a video that will present the CICD of the application in\n    a new empty tenant and a customer patch to show the factory end to end.\n\n\n*Note*: A complex feature or bug fix could be delivered several times,\nimproving the application between each delivery. Your customer does not\nrequire this to be delivered just once. They prefer to see changes frequently.\n  But the overall application service must not be impacted by such update.\n\n  In the context of this training, no complex feature or bug fix will be\n  requested by your teachers.\n\n*Another Note*: github is mandatory for the delivery. However, you can\nuse any other scm solutions to meet your needs. But you must update\nregularly the github repo with **history**\n\n## Teachers interaction with students\n\n\n### Platforms\n\nTeachers will provide a remote access (though VPN) to :\n\n* the *customer production platform* (known as *Production environment*)\n    (2 servers pre-installed with a CentOS 7 distribution)\n\n    Your development team will have to setup them with (packstack)[https://www.rdoproject.org/install/packstack/.\n\n    Your development team will deploy the customer application and application\n    health control on it.\n\n* a runnable *company Openstack tenant* (known as *Reference environment*)\n    to install your software factory.\n    In this factory, you will be able to\n    * develop anything requested by your customers, or proposed by your team\n        for improvement/bug fix.\n    * test your application and his delivery\n    * control the application and software factory health\n\n\n### Roles\n\nYour teachers will take and behave with 2 different roles:\n\n- *Customer representative*.\n    He will support the 2 Production systems that you will use to deliver\n    your application.\n    \u003cbr\u003eto contact your customer, use the mailing list :\n    ensimag-customer@lists.osp.hpe.com\n\n- *Your company IT* who hosts your openstack tenant.\n    \u003cbr\u003eTo contact your company IT team, use the mailing list:\n    ensimag-internal@lists.osp.hpe.com\n\nWhen you contact *your customer* or *your company*, remind your group number.\n\n### Training support\n\nOutside of these roles that your teachers will have, you can get support on\nthe overall training subject, by mail or during the different sessions, to:\n* Ask question,\n* Get help (VPN Access, platform setup, expertise)\n* Discuss\n\nThe mailing list is:  ensimag-internal@lists.osp.hpe.com\n\n# Agenda\n\nEach session is 3 hours long\n\n## First session\n\n * Project explanation: Overall Goals \u0026 method (groups, prod platform, TD systems for tests). No formal solution will be directly given, students will have to build the solution by themselves. Many approaches are possible.  The teachers team role will be after the 2 first sessions and generic presentations on all concepts to help them in the realization of that application and its setup. (Christophe / René)\n * OpenStack architecture \u0026 example (Bruno)\n * Docker (Bruno)\n * *Company Openstack tenant* (known as Reference Environment) platform\n    explanation (Vincent)\n * OpenVPN setup\n * Waystation creation (see below)  --\u003e pb need group defined.\n * Home work:\n   * Continue to explore OpenStack from both UI \u0026 CLI\n   * Explore tools to use for the factory and automation systems\n   * Create 9 groups of 5 students (one country per group), assign specialization (ops, devs, middleware, ... + backup), tool choice left to students, but licensing should be correct (prefer Open Source)\n\n## Second session\n\n * DevOps fundamentals (Christophe)\n * Application overview (René)\n * Infrastructure as Code: OpenStack API as TD\n * Project explanation: Architecture of the use case - Specifications - Design Constraints \u0026 Goals (GitHub, automation, )\n * Home work: Continue to explore OpenStack API (Dev), DevOps concept and tools, Start Prod Infra setup\n\n## Third session\n\n* Team member role and responsibility. Assigning tasks... Who does what?\n    The customer like to see that...\n* Design and implement a flow to develop and deliver application architecture\n* Prod infra setup continued: Ability to launch a VM from an image using a heat template, attached to a network and a storage, and an object storage. private and public net are available and a floating IP attached to the VM.\n* Application architecture done: microservices identified, HA solved, Scalability solved. Design done (Paper work, UML ?).\n\n## Fourth session\n\n * Prod infra setup finished: Ability to launch a VM from an image using a heat template, attached to a network and a storage, and an object storage. private and public net are available and a floating IP attached to the VM.\n * Application architecture development ongoing\n * Factory improvement to deliver fisrt version of the application ecosystem\n\n## Fifth session\n\n * Prod infra setup / factory review if needed\n * Application ecosystem and software factory improved to deliver more.\n\n## Sixth session\n\n * Application ecosystem continuous improvement.\n\n## Seventh session\n\n * Synthesis and integration\n * Group Presentation\n * Integrate a customer request (feature or bug fix) in the factory\n\n## Eigth session\n\n * Evaluation of the projects\n\n# Evaluation\n\nEvaluation will be 25' Maximum per group including 5' for Q\u0026A.\nYou will present :\n- application ecosystem architecture\n- factory architecture\n- your roles,\n- tasks done,\n- code, commits,\n- Factory flow from development to deployment\n- Process used and description (how you work together)\n\nThen, the functional evaluation will be done on architecture with\nexplanation of choices, methods and tools used.\n\n * Reminder: Plan to have a backup video.\n * A presentation to explain the major steps and choices might be useful,\n    but not mandatory\n\nSend all deliverable planned in advance of the evaluation (before 7th session)\nto allow time for teachers to look at them. Think to provide access if\nyour project is not public.\n\n| Points | Topic to evaluate |\n| ------ | ----------------- |\n| **5**  | **Dev team**\u003cbr\u003e\u003cul\u003e\u003cli\u003eOn Gihub:\u003c/li\u003e\u003cul\u003e\u003cli\u003eAutomation code to test and deploy\u003c/li\u003e\u003cli\u003ePerformance and tests results\u003c/li\u003e\u003cli\u003eApplication code\u003c/li\u003e\u003c/ul\u003e\u003cli\u003eApplication design document\u003c/li\u003e\u003cli\u003ePresent the automatic deployment of the application in a tenant and make reliability checks.\u003c/li\u003e\u003c/ul\u003e|\n| **5**  | **Factory (Ops) team**\u003cbr\u003e\u003cul\u003e\u003cli\u003eAvailable\u003c/li\u003e\u003cli\u003eOperational\u003c/li\u003e\u003cli\u003eWith the mandatory components (Agile/CI/CD/...)\u003c/li\u003e\u003cli\u003eAnd optional ones needed by the development teams\u003c/li\u003e\u003cli\u003eOn Gihub:\u003c/li\u003e\u003cul\u003e\u003cli\u003eHeat templates/ansible playbooks/scripts for Infra group\u003c/li\u003e\u003c/ul\u003e|\n| **5**  | **Production services**\u003cbr\u003e\u003cul\u003e\u003cli\u003eProduction IaaS up and running based en packstack\u003c/li\u003e\u003cli\u003eApplication still working, independently\u003cbr\u003eSupport for failure and scalability\u003c/li\u003e\u003cli\u003eSelf healing\u003c/li\u003e\u003cli\u003eMonitoring\u003c/li\u003e\u003c/ul\u003e |\n| **5**  | **Project life**\u003cbr\u003e\u003cul\u003e\u003cli\u003eImprovement/bug fix timeline from dev to prod\u003c/li\u003e\u003cli\u003eAgile project plan\u003c/li\u003e\u003cli\u003eChatOps, Issue tracking, support\u003c/li\u003e\u003cli\u003eUpstream relationship\u003c/li\u003e\u003c/ul\u003e |\n\n\n# How to create your bastion vm on Reference environment\n\n## Connection :\n\n1. Connect using OpenVPN.\nThe lab network uses\n- HPE Blades, for the production environment\n- HPE Moonshot cartridges, for the staging environment\n\nall are located in the HPE Customer Innovation Center and reached through a dedicated VPN.\n\nEach students group will receive a Lab number (X) from the instructors team\n\nAll students servers receive their fixed-assigned addresses using a DHCP server. In order to connect to them, a VPN is provided. You need to activate that VPN by launching on Linux the following commands:\n\n\u003e **WARNING!!** The FTP service will be opened ONLY during the session 1.\n\u003e\n\u003e Keep your keys somewhere else.\n\n```\n$ mkdir -p ~/lab\n$ cd ~/lab\n$ wget ftp://ftp.hpecic.net/pub/openvpn/ca.crt\n$ wget ftp://ftp.hpecic.net/pub/openvpn/lab2017.key\n$ wget ftp://ftp.hpecic.net/pub/openvpn/lab2017.crt\n$ wget ftp://ftp.hpecic.net/pub/openvpn/vpnlab2017.conf\n$ sudo openvpn --config vpnlab2017.conf\n```\n\nFor those of you unlucky using a Windows desktop system, then install first wget from http://labossi.hpintelco.net/win/wget.exe or http://labossi.hpintelco.net/win/wget64.exe and then openvpn in case you don't have it from http://openvpn.net/index.php/open-source/downloads.html (internal mirror at http://labossi.hpintelco.net/win/)\n\nYou need to launch a cmd command as **Administrator** on your system (use the\nStart/windows button, type `cmd` and right click on the icon appearing to select\n`Run as Administrator`) and then you have to run in it\n\n```\nC:\\WINDOWS\\SYSTEM32\u003e md C:\\openvpn\nC:\\WINDOWS\\SYSTEM32\u003e cd C:\\openvpn\n```\nDownload the 4 files previously mentioned in the `wget` command under\n`C:\\openvpn`. Then issue:\n\n```\nC:\\openvpn\u003e openvpn --config vpnlab2017.conf\n```\n\nFor those of you unlucky using a MacOS desktop system, then install a compatible openvpn tool in case you don't have it already from https://code.google.com/p/tunnelblick/. Then launch TunnelBlick using that conf file.\n\nFrom now on, you should be able to connect using `ssh` to the systems.\n\nFor those of you still unlucky using a Windows desktop system, then install\n`putty` in case you don't have it from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html.\n\nThen launch `putty` in the run command interface and log on your target system.\n\n2. Connect to the Openstack Dashboard.\n    Reference OpenStack dashboard IP:\n3. To log use : http://10.11.50.7/\n    * user name : LabX    (X = number of your group)\n    * password : The password for your group that you should have received by mail.\n\nAt that step, you shoud be connected in your respective tenant (groupeX) with a fresh environment.\nYou need to create a minimal infrastructure, a bastion server using the dashboard.\n\nThis openstack has a lot more services than the one we used in the first session. (note that swift and cinder are not yet available which is a problem only for service P and B)\nThe neutron network service is available, and you will have to use it to create your networks that will host the bastion server.\n\n## Create a private network:\n\n1. Open the menu and click on network then choose networks subitem.\n2. Create a new network.\n    * Name : you can use whatever name, but as an example we will use \"private\"\n    * Subnet name : private_subnet\n    * Network address : CIDR of your network, you can choose what you want, here as an example we can use 192.168.5.0/24.\n    * Gateway IP : by default it will use the first IP of the range\n    * In subnet details just provide the DNS : 10.3.156.12\n\nThis will be your private network, we will deploy our admin VMs inside that network.\nYou can see there is another network called external-network. This network is a public one. It will be used to provide access to VM from the outside by mapping a floating ip.\nHowever before that, we need to connect private network and external network with a router.\n\n## Create a router:\n\n1. Open the menu and click on network then choose routers subitem.\n2. Create a router\n    * Name : router1  (as an example)\n    * External network : public\n3. Click on the router1 just created and add an interface to the private network.\n4. You can verify in \"Network Topology\" that you have a router in beetween external network and internal one.\n\nNow the networking should be in place.\n\n## Create your bastion (admin) server and access it :\n\n1. Deploy a new vm via the dashboard (launch a new instance)\n    * Name: bastion\n    * Image: Fedora or Ubuntu (the one you prefer, they have both recent openstack tools)\n    * Flavor: v1.m1.d5\n    * Network: private1  (not the external)\n    * Security group: default\n    * Key pair: Generate your keypair or provide your ssh pub key.\n\n2. Associate a floating ip to your server (via network --\u003e Accès \u0026 Sécurité --\u003e IP flottantes)\nThis is a bit tricky, you need first to allocate a floating ip (this will give you an IP on the external network)\nThen you will associate this external ip to your bastion VM on the private network.\n\nEx : in the instance dashboard you should see in the IP column :\nVM name :bastion\n\n    192.168.5.5\n\nFloating IPs:\n\n    10.11.53.15\n\n\n3. Open the menu and click on compute then choose access and security subitem.\n4. Manage the default security group to allow Ingress ssh(port 22)\n5. You should be able to log on your vm using the floating ip and the ssh key created before.   (please ask if you need assistance with ssh)\n    Ex: ssh fedora@10.11.53.15 or ssh ubuntu@10.11.53.15\n\n6. You can install the openstack client to manage the API and do automation. (assuming there is no errors in the above parts)\nEx: dnf install python-openstackclient    --\u003e this will install a recent version of the openstack client on Fedora\n7. Get your openrc files by opening the menu and click on compute then choose access and security subitem and menu API access.\nHere you can download a rcfile that will give you all the settings to connect to your environment.\nYou just need to source that file to export the OS* required environment variables.\n\nNote :\nConsider the default security group as your admin subnet. Restrict access to it to only ssh.\nApplications should be deployed in their respective networks and corresponding security groups.\n\nAdvice 1 : do not create a lot of security groups, you will become crazy managing them. A good approach is to map a security group per network and open the required ports.\n\nAdvice 2 : look at the orchestration part and mostly service heat. Sounds like an easy way to deploy stuff although not mandatory.\n\nAdvice 3 : using IP is painfull in a cloud environment, prefer names.\n\n# Production environment\n\nEach group will have 2 servers pre-installed with a CentOS 7 distribution.\nYour development team will have to setup them with packstack: https://www.rdoproject.org/install/packstack/.\n\n![Image](https://github.com/uggla/cloud_native_app/blob/master/schema/Infra-prod.jpg)\n\n## Servers and External IP assigments\n\nLab ID | IP Server 1 | IP Server 2 | FIP DHCP start | FIP DHCP end |\n-------|-------------|-------------|----------------|--------------|\nLab 1 | 10.11.51.138 | 10.11.51.174| 10.11.54.10 | 10.11.54.29 |\nLab 2 | 10.11.51.140 | 10.11.51.141 | 10.11.54.30 | 10.11.54.49 |\nLab 3 | 10.11.51.142 | 10.11.51.143 | 10.11.54.50 | 10.11.54.69 |\nLab 4 | 10.11.51.144 | 10.11.51.145 | 10.11.54.70 | 10.11.54.89 |\nLab 5 | 10.11.51.161 | 10.11.51.162 | 10.11.54.90 | 10.11.54.109 |\nLab 6 | 10.11.51.163 | 10.11.51.164 | 10.11.54.110 | 10.11.54.129 |\nLab 7 | 10.11.51.165 | 10.11.51.159 | 10.11.54.130 | 10.11.54.149 |\nLab 8 | 10.11.51.167 | 10.11.51.173 | 10.11.54.150 | 10.11.54.169 |\nLab 9 | 10.11.51.169 | 10.11.51.170 | 10.11.54.170 | 10.11.54.189 |\nLab 10 | 10.11.51.171 | 10.11.51.172 | 10.11.54.190 | 10.11.54.209 |\n\n## Tips for PackStack deployment\n\n- Update your servers  \n- Install packstack packages (step 0 to step 2)  \n- Generate and update an answer file: packstack --gen-answer-file=ensimag-packstack.txt  \nCONFIG_NTP_SERVERS=10.3.252.26  \nCONFIG_NEUTRON_ML2_TYPE_DRIVERS=vxlan,flat,vlan  \nCONFIG_NEUTRON_ML2_FLAT_NETWORKS=extnet  \nCONFIG_NEUTRON_ML2_VLAN_RANGES=extnet:2232:2232  \nCONFIG_NEUTRON_OVS_BRIDGE_IFACES=br-ex:eno1  \nCONFIG_NEUTRON_OVS_BRIDGES_COMPUTE=br-ex  \nCONFIG_PROVISION_DEMO=n  \n\n- Deploy your packstack : packstack --answer-file=ensimag-packstack.txt\n\n- If your deployment is successful, try to access your OpenStack via Horizon\n\n- Connect with the external network:  \n**Source your rc file.**  \n**Create network:** neutron net-create public --router:external --provider:network_type vlan  \n--provider:physical_network extnet --provider:segmentation_id 2232  \n**Create subnet:** neutron subnet-create --name public-subnet --enable_dhcp=False  \n--allocation-pool=start=10.11.54.X,end=10.11.54.Y --gateway=10.11.54.1 public 10.11.54.1/24  \n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fuggla%2Fcloud_native_app","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fuggla%2Fcloud_native_app","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fuggla%2Fcloud_native_app/lists"}