Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
user:kluong:running_a_service_in_production [2022/10/07 17:19] kluong |
user:kluong:running_a_service_in_production [2022/10/12 18:20] (current) kluong |
||
|---|---|---|---|
| Line 3: | Line 3: | ||
| I wanted to drop down some of my notes about running services in production - for many of you folks, this is probably one of the first times you'll be touching a service. | I wanted to drop down some of my notes about running services in production - for many of you folks, this is probably one of the first times you'll be touching a service. | ||
| - | **What is a service?** | + | ==== What is a service? ==== |
| More generically, a service is something that is running somewhere on a machine (or a set of machines) somewhere that does something. For most folks, the most familiar thing is a website. Take hawaii.edu for example - it's a website but there is a service (or services) running somewhere that serves HTTP requests from user's browsers. | More generically, a service is something that is running somewhere on a machine (or a set of machines) somewhere that does something. For most folks, the most familiar thing is a website. Take hawaii.edu for example - it's a website but there is a service (or services) running somewhere that serves HTTP requests from user's browsers. | ||
| Line 9: | Line 9: | ||
| For our lab, the gateway is an example of a service; it's running in the background to collect sensor data and putting it into postgres. | For our lab, the gateway is an example of a service; it's running in the background to collect sensor data and putting it into postgres. | ||
| - | **Running a service** | + | ==== Running a service ==== |
| Since a service is just some program that's running on a machine, you could easily just start up on a desktop session, inside someone's terminal shell or something. This would work - the program would respond to requests. However, what happens if the machine restarts? What happens if the user logs out? And what happens if there is no one physically there to start the program again. | Since a service is just some program that's running on a machine, you could easily just start up on a desktop session, inside someone's terminal shell or something. This would work - the program would respond to requests. However, what happens if the machine restarts? What happens if the user logs out? And what happens if there is no one physically there to start the program again. | ||
| Line 19: | Line 19: | ||
| As part of running a service in production, you want to make sure that the service stays up so it's important to use something like systemd to manage this. | As part of running a service in production, you want to make sure that the service stays up so it's important to use something like systemd to manage this. | ||
| + | Here's an example of a very simple systemd service file: | ||
| - | **Deployments and version control ** | + | <code> |
| + | [Unit] | ||
| + | Description=Example app | ||
| + | After=network.target | ||
| + | |||
| + | [Service] | ||
| + | Type=simple | ||
| + | User=scel | ||
| + | WorkingDirectory=/home/example-user/example-app | ||
| + | ExecStart=/home/example-user/example-app/run.sh --some-flag | ||
| + | Restart=always | ||
| + | |||
| + | [Install] | ||
| + | WantedBy=multi-user.target | ||
| + | </code> | ||
| + | |||
| + | This could be installed in `/etc/systemd/system/example-app.service` | ||
| + | |||
| + | After installing it, you can reload the config: | ||
| + | |||
| + | <code> | ||
| + | systemctl daemon-reload | ||
| + | systemctl start example-app.service | ||
| + | </code> | ||
| + | |||
| + | |||
| + | ==== Deployments and version control ==== | ||
| Line 27: | Line 54: | ||
| Deployments should be tied to some sort of version control (like git), or some sort of artifact repository like debian repositories. You want to avoid having deployment be freely editable by anyone with access to the machine, since changes will be hard to if not difficult to track. | Deployments should be tied to some sort of version control (like git), or some sort of artifact repository like debian repositories. You want to avoid having deployment be freely editable by anyone with access to the machine, since changes will be hard to if not difficult to track. | ||
| + | {{ :user:kluong:codebase-deploys.png?200 |}} | ||
| - | **Staging deployments** | + | |
| + | |||
| + | ==== Staging deployments ==== | ||
| Often times when running production services you don't always want to push to production. You want some sort of environment prior to production that you can break if needed. Such an environment is called a staging environment and is pretty standard for many services. | Often times when running production services you don't always want to push to production. You want some sort of environment prior to production that you can break if needed. Such an environment is called a staging environment and is pretty standard for many services. | ||
| Line 34: | Line 64: | ||
| To have a staging environment, you may need to mirror some of the configuration that you have in production. A staging environment can have a different database or database table; or even run on a completely different machine. There are various tradeoffs with how deep you want to go, so the details of an exact staging environment is up to the development team. | To have a staging environment, you may need to mirror some of the configuration that you have in production. A staging environment can have a different database or database table; or even run on a completely different machine. There are various tradeoffs with how deep you want to go, so the details of an exact staging environment is up to the development team. | ||
| - | + | ==== Further reading ==== | |
| - | **Further reading** | + | |
| I intended this page to be an intro of sorts for what you'll start with in the lab. A lot of the above sections are covered in the definition of a "12 factor app". This is useful to read, as it covers a lot of the principals that get used in practice. | I intended this page to be an intro of sorts for what you'll start with in the lab. A lot of the above sections are covered in the definition of a "12 factor app". This is useful to read, as it covers a lot of the principals that get used in practice. | ||
| https://12factor.net/ | https://12factor.net/ | ||