4 ms·

Please note that this describes something you would do for a toy project. If you do this for work you probably want to: * Install NPM in a way that you can upg

by xorcist 11y ago

Please note that this describes something you would do for a toy project. If you do this for work you probably want to: * Install NPM in a way that you can upgrade easily. Your package manager was designed to do this, so use it. Never ever put untracked files in the system directories. * Don't git clone into production. You need to know which version was deployed when and where. At the very least set a tag. Better yet, roll a package from that tag (see above) which you then can sign and store. It's very easy and there are tools to help. * Schedule when and how you upgrade your operating system, NPM, and your application. To do this you need a way to take an application out of production, which brings us to... * You generally want a load balancer or some sort of web server between the world and your application. This could be as simple as an Apache or nginx. Don't muck about with port forwards! * And most importantly, document this down to every command in the internal wiki! Even better, write a Puppet/Salt/Ansible file and put it under version control. In short: Tools exist for a reason. Use them. Don't hack files manually until you master the tools and know why they exist.

nailer 11y ago
> * Install NPM in a way that you can upgrade easily. Your package manager was designed to do this, so use it. Never ever put untracked files in the system directories. The articles uses the package manager - specifically, the article directs people to install node using nodesource's RPM and dpkg node packages (npm is included with node), and only mentions tarballs if these don't exist for your OS. > * Schedule when and how you upgrade your operating system, NPM, and your application. To do this you need a way to take an application out of production, which brings us to... > You generally want a load balancer or some sort of web server between the world and your application. Hence covering that and load balancing with HAProxy in the article. This is mentioned in the introduction. > * And most importantly, document this down to every command in the internal wiki! Even better, write a Puppet/Salt/Ansible file and put it under version control. Hence mentioning exactly that in the opening few paragraphs. It's very clear you didn't read the article before commenting.
- kiallmacinnes 11y ago
  >> * Install NPM in a way that you can upgrade easily. Your package manager was designed to do this, so use it. Never ever put untracked files in the system directories. > The articles uses the package manager - specifically, the article directs people to install node using nodesource's RPM and dpkg node packages (npm is included with node), and only mentions tarballs if these don't exist for your OS. Sure, but it also advises users that it's generally OK to extract tarballs into /usr/local. While this clearly is OK in some circumstances, the target audience for this article clearly aren't in a position to make that decision, or understand the consequences of doing this. The article could have suggested "/opt/node" for example and avoided the issue at the expense of explaining how PATH variables work.
  - nailer 11y ago
    So you'd prefer, if no packages are available, unpackaged software be installed to /opt rather than /usr/local? OK. The FHS forbids distros from installing software to either location. See http://www.pathname.com/fhs/2.2/fhs-4.9.html http://www.pathname.com/fhs/2.2/fhs-4.9.html: > "The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr."
    - kiallmacinnes 11y ago
      > So you'd prefer, if no packages are available, unpackaged software be installed to /opt rather than /usr/local? OK. Ah, I did miss the subfolder. This is a very unusual convention for installation into /usr/local. Typically, this is what modern day usage of /opt looks like. > The FHS forbids distros from installing software to either location. > See http://www.pathname.com/fhs/2.2/fhs-4.9.html http://www.pathname.com/fhs/2.2/fhs-4.9.html: Correct, both options are valid per the FHS. Yet, the description for /opt describes the pattern used in your example. See http://www.pathname.com/fhs/2.2/fhs-3.12.html http://www.pathname.com/fhs/2.2/fhs-3.12.html: "A package to be installed in /opt must locate its static files in a separate /opt/<package> directory tree, where <package> is a name that describes the software package."
pavlov 11y ago
Tools exist for a reason. Use them. Don't hack files manually until you master the tools and know why they exist. I feel it's often the other way around: don't hack around with big powerful tools until you know what the underlying problem is and what steps are actually needed to solve it.
- kiallmacinnes 11y ago
  I think the GP post addressed this in their opening line, if you don't know what the underlying problem is, you're dealing with a toy project (Be it for pleasure, prototype, R&D) and his advice isn't aimed at these projects.
joeyspn 11y ago
> Please note that this describes something you would do for a toy project. Exactly my thoughts... this is for toy projects. It's 2016 and we have proper tools like PM2 [0], StrongPM [1], or even better, Serverless [2] (this is only for AWS but sooo cool) ... [0] https://github.com/Unitech/pm2 https://github.com/Unitech/pm2 [1] http://strong-pm.io/ http://strong-pm.io/ [2] https://github.com/serverless/serverless https://github.com/serverless/serverless
- nailer 11y ago
  Author here. - The article uses systemd for process monitoring rather than PM2 since it's built into the OS. - The article uses HAProxy as a load balancer. - Ansible playbooks, Dockerfiles, and the AWS API are all mentioned in the opening section of the article. Serverless sounds fine too. Personally I use http://mikemaccana.com/images/work/screenshots/firework-0.png http://mikemaccana.com/images/work/screenshots/firework-0.pn... which I made using the AWS API. Either way, you will need some logic to capture inside these tools. Rather than write an article on Dockerfiles, Ansible playbooks, or the AWS or DO APIs, the article covers the devops basics one needs to know before using these tools. 'Use ${TOOL}' doesn't help you create or understand the contents of ${TOOL}s Dockerfile.
  - joeyspn 11y ago
    > 'Use ${TOOL}' doesn't help you create or understand the contents of ${TOOL}s Dockerfile. Many tools are popular because they provide powerful and convenient abstractions. For many folks, it's all about saving time (and therefore money). There's value in leaving the underlying working internals to specialists (that's why we don't need to understand the linux In-kernel API when we use Ubuntu Server's networking)
    - mikemaccana 11y ago
      Totally agreed, there's certainly a place for tools that don't need DevOps skills, and many places - typically PaaS - that take care of this. However many developers wish to have more control over their environment than what a PaaS provides, and a lot of the tools they'd use for that - Ansible, Docker, etc - require basic DevOps skills. [replying from old account due to rate limit]
joshmn 11y ago
Lock down your damn firewall too.

by xorcist 11y ago

nailer 11y ago

> * Install NPM in a way that you can upgrade easily. Your package manager was designed to do this, so use it. Never ever put untracked files in the system directories. The articles uses the package manager - specifically, the article directs people to install node using nodesource's RPM and dpkg node packages (npm is included with node), and only mentions tarballs if these don't exist for your OS. > * Schedule when and how you upgrade your operating system, NPM, and your application. To do this you need a way to take an application out of production, which brings us to... > You generally want a load balancer or some sort of web server between the world and your application. Hence covering that and load balancing with HAProxy in the article. This is mentioned in the introduction. > * And most importantly, document this down to every command in the internal wiki! Even better, write a Puppet/Salt/Ansible file and put it under version control. Hence mentioning exactly that in the opening few paragraphs. It's very clear you didn't read the article before commenting.

kiallmacinnes 11y ago
>> * Install NPM in a way that you can upgrade easily. Your package manager was designed to do this, so use it. Never ever put untracked files in the system directories. > The articles uses the package manager - specifically, the article directs people to install node using nodesource's RPM and dpkg node packages (npm is included with node), and only mentions tarballs if these don't exist for your OS. Sure, but it also advises users that it's generally OK to extract tarballs into /usr/local. While this clearly is OK in some circumstances, the target audience for this article clearly aren't in a position to make that decision, or understand the consequences of doing this. The article could have suggested "/opt/node" for example and avoided the issue at the expense of explaining how PATH variables work.
- nailer 11y ago
  So you'd prefer, if no packages are available, unpackaged software be installed to /opt rather than /usr/local? OK. The FHS forbids distros from installing software to either location. See http://www.pathname.com/fhs/2.2/fhs-4.9.html http://www.pathname.com/fhs/2.2/fhs-4.9.html: > "The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr."
  - kiallmacinnes 11y ago
    > So you'd prefer, if no packages are available, unpackaged software be installed to /opt rather than /usr/local? OK. Ah, I did miss the subfolder. This is a very unusual convention for installation into /usr/local. Typically, this is what modern day usage of /opt looks like. > The FHS forbids distros from installing software to either location. > See http://www.pathname.com/fhs/2.2/fhs-4.9.html http://www.pathname.com/fhs/2.2/fhs-4.9.html: Correct, both options are valid per the FHS. Yet, the description for /opt describes the pattern used in your example. See http://www.pathname.com/fhs/2.2/fhs-3.12.html http://www.pathname.com/fhs/2.2/fhs-3.12.html: "A package to be installed in /opt must locate its static files in a separate /opt/<package> directory tree, where <package> is a name that describes the software package."

pavlov 11y ago

Tools exist for a reason. Use them. Don't hack files manually until you master the tools and know why they exist. I feel it's often the other way around: don't hack around with big powerful tools until you know what the underlying problem is and what steps are actually needed to solve it.

kiallmacinnes 11y ago
I think the GP post addressed this in their opening line, if you don't know what the underlying problem is, you're dealing with a toy project (Be it for pleasure, prototype, R&D) and his advice isn't aimed at these projects.

joeyspn 11y ago

> Please note that this describes something you would do for a toy project. Exactly my thoughts... this is for toy projects. It's 2016 and we have proper tools like PM2 [0], StrongPM [1], or even better, Serverless [2] (this is only for AWS but sooo cool) ... [0] https://github.com/Unitech/pm2 https://github.com/Unitech/pm2 [1] http://strong-pm.io/ http://strong-pm.io/ [2] https://github.com/serverless/serverless https://github.com/serverless/serverless

nailer 11y ago
Author here. - The article uses systemd for process monitoring rather than PM2 since it's built into the OS. - The article uses HAProxy as a load balancer. - Ansible playbooks, Dockerfiles, and the AWS API are all mentioned in the opening section of the article. Serverless sounds fine too. Personally I use http://mikemaccana.com/images/work/screenshots/firework-0.png http://mikemaccana.com/images/work/screenshots/firework-0.pn... which I made using the AWS API. Either way, you will need some logic to capture inside these tools. Rather than write an article on Dockerfiles, Ansible playbooks, or the AWS or DO APIs, the article covers the devops basics one needs to know before using these tools. 'Use ${TOOL}' doesn't help you create or understand the contents of ${TOOL}s Dockerfile.
- joeyspn 11y ago
  > 'Use ${TOOL}' doesn't help you create or understand the contents of ${TOOL}s Dockerfile. Many tools are popular because they provide powerful and convenient abstractions. For many folks, it's all about saving time (and therefore money). There's value in leaving the underlying working internals to specialists (that's why we don't need to understand the linux In-kernel API when we use Ubuntu Server's networking)
  - mikemaccana 11y ago
    Totally agreed, there's certainly a place for tools that don't need DevOps skills, and many places - typically PaaS - that take care of this. However many developers wish to have more control over their environment than what a PaaS provides, and a lot of the tools they'd use for that - Ansible, Docker, etc - require basic DevOps skills. [replying from old account due to rate limit]

joshmn 11y ago

Lock down your damn firewall too.