TARDIS Project

User Tools

Site Tools

Trace:
howto:webapp

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
howto:webapp [2023/07/29 11:10] – created tcmalhowto:webapp [2025/03/29 07:13] (current) – [Keeping it running] merlin
Line 11: Line 11:
 If your content is going to be served the same to everyone, it's a *static web page*. This includes JS apps that, once loaded, make requests to somewhere else. If your content is going to be served the same to everyone, it's a *static web page*. This includes JS apps that, once loaded, make requests to somewhere else.
  
-Deploying these is super simple - you can build them with Gitlab (if you need to) and then deploy them on our pages instance. [[tutorials:5|This page]] details how.+Deploying these is super simple - you can build them with Gitlab (if you need to) and then deploy them on our pages instance. [[howto:homepage|This page]] details how.
  
 ===== Any other applications ===== ===== Any other applications =====
Line 21: Line 21:
 Firstly, consider what you need to run alongside your actual app. If you need some kind of database (which is likely), you can use our managed MySQL server. See [[https://console.tardisproject.uk|the tardis console]] to set one up. Firstly, consider what you need to run alongside your actual app. If you need some kind of database (which is likely), you can use our managed MySQL server. See [[https://console.tardisproject.uk|the tardis console]] to set one up.
  
-Now you need to actually deploy your code. To start with, get it running on the ''sandbox'' vm in some way. [[tutorials:4|Get your code onto the VM]], and also [[tutorials:3|install any extra languages or applications you need]].+Now you need to actually deploy your code. To start with, get it running on the ''sandbox'' vm in some way. [[howto:files|Get your code onto the VM]], and also [[howto:languages|install any extra languages or applications you need]].
  
 The rest of the setup largely depends on your language, and framework. For Python, you'll probably want to set up a virtual environment, or for Node you might just need to run ''npm install''. The rest of the setup largely depends on your language, and framework. For Python, you'll probably want to set up a virtual environment, or for Node you might just need to run ''npm install''.
Line 33: Line 33:
 Now you've gotten everything running within the network, it's time to put it on the internet! Before you do this, make an effort to check for any security holes or things that should only be exposed for development. Now you've gotten everything running within the network, it's time to put it on the internet! Before you do this, make an effort to check for any security holes or things that should only be exposed for development.
  
-Now, head to the [[https://console.tardisproject.uk|Tardis console]] and hit ''Manage endpoints''. An endpoint is just a forwarding from our publicly-accessible server, to an application inside the network. +Now, head to the [[https://console.tardisproject.uk|Tardis console]] and hit ''Endpoints''. An endpoint is just a forwarding from our publicly-accessible server, to an application inside the network. 
  
 You can create a new endpoint with your domain and whatever prefix you'd like. The target IP address will be ''192.168.0.130'' (the internal ip of the sandbox vm), and the target port will be whatever you set your application up to listen to. You can create a new endpoint with your domain and whatever prefix you'd like. The target IP address will be ''192.168.0.130'' (the internal ip of the sandbox vm), and the target port will be whatever you set your application up to listen to.
 +
 +If you want to use a custom domain, [[https://tardisproject.uk/chat|let an admin know]] and they'll set it up for you.
  
 === Endpoint options === === Endpoint options ===
 +
 +There are a couple of advanced options. In most cases you won't need to touch them, but if you have problems you should take a look.
  
 In most cases, you won't need to use HTTPs from the proxy to the target. You can test this by running ''curl localhost:<port>'' on the sandbox vm - if it succeeds then you don't need it. In most cases, you won't need to use HTTPs from the proxy to the target. You can test this by running ''curl localhost:<port>'' on the sandbox vm - if it succeeds then you don't need it.
Line 72: Line 76:
   - Hit ''Ctrl+b'', then ''d''. You'll go back to your original terminal, and see a message like ''[detached (from session 0)]''   - Hit ''Ctrl+b'', then ''d''. You'll go back to your original terminal, and see a message like ''[detached (from session 0)]''
  
-Your app is now running in the background - feel free to log out and it will stay running. If you want to get back to it to see logs or stop it, run ''tmux attach'' whenever you want.+Your app is now running in the background - feel free to log out and it will stay running. If you want to get back to it to see logs or stop it, run ''tmux attach'' whenever you want. However, if we restart the sandbox VM, which may happen due to maintenance, your app will not start back up.
  
 === Systemd === === Systemd ===
Line 114: Line 118:
 === Docker / Orchestrators === === Docker / Orchestrators ===
  
-Docker is a tool for packaging up applications with all their dependencies, so they can be run exactly the same on your server as on your local device. If you want to learn more about it, see the first part of [[howto:learn_k8s|this page]]+Docker is a tool for packaging up applications with all their dependencies, so they can be run exactly the same on your server as on your local device. If you want to learn more about it, see the first part of [[howto:specific:learn_k8s|this page]]
  
 You can use rootless docker on the sandbox VM, although you'll need an admin to enable lingering for you just like with systemd. Just detach from the docker container once you run it, and it will stay running. You can also use docker compose or any other tools you like for making docker easier. You can use rootless docker on the sandbox VM, although you'll need an admin to enable lingering for you just like with systemd. Just detach from the docker container once you run it, and it will stay running. You can also use docker compose or any other tools you like for making docker easier.
Line 120: Line 124:
 You can build a docker image for your app right on the sandbox VM, or you can build it somewhere else (including from CI) and push it to the [[https://docs.gitlab.com/ee/user/packages/container_registry/|Gitlab container registry]], then pull it to the sandbox VM.  You can build a docker image for your app right on the sandbox VM, or you can build it somewhere else (including from CI) and push it to the [[https://docs.gitlab.com/ee/user/packages/container_registry/|Gitlab container registry]], then pull it to the sandbox VM. 
  
-Lastly, you can use our [[howto:learn_k8s|Kubernetes cluster]] to deploy dockerised applications onto. This is great for if you want to automate updates or have a lot of interconnected applications to deploy, but can have a steep learning curve.+Lastly, you can use our [[howto:specific:learn_k8s|Kubernetes cluster]] to deploy dockerised applications onto. This is great for if you want to automate updates or have a lot of interconnected applications to deploy, but can have a steep learning curve.
howto/webapp.1690629026.txt.gz · Last modified: 2023/07/29 11:10 by tcmal