One place for hosting & domains

      November 2019

      How To Use Node.js Modules with npm and package.json


      The author selected the Open Internet/Free Speech Fund to receive a donation as part of the Write for DOnations program.

      Introduction

      Because of such features as its speedy Input/Output (I/O) performance and its well-known JavaScript syntax, Node.js has quickly become a popular runtime environment for back-end web development. But as interest grows, larger applications are built, and managing the complexity of the codebase and its dependencies becomes more difficult. Node.js organizes this complexity using modules, which are any single JavaScript files containing functions or objects that can be used by other programs or modules. A collection of one or more modules is commonly referred to as a package, and these packages are themselves organized by package managers.

      The Node.js Package Manager (npm) is the default and most popular package manager in the Node.js ecosystem, and is primarily used to install and manage external modules in a Node.js project. It is also commonly used to install a wide range of CLI tools and run project scripts. npm tracks the modules installed in a project with the package.json file, which resides in a project’s directory and contains:

      • All the modules needed for a project and their installed versions
      • All the metadata for a project, such as the author, the license, etc.
      • Scripts that can be run to automate tasks within the project

      As you create more complex Node.js projects, managing your metadata and dependencies with the package.json file will provide you with more predictable builds, since all external dependencies are kept the same. The file will keep track of this information automatically; while you may change the file directly to update your project’s metadata, you will seldom need to interact with it directly to manage modules.

      In this tutorial, you will manage packages with npm. The first step will be to create and understand the package.json file. You will then use it to keep track of all the modules you install in your project. Finally, you will list your package dependencies, update your packages, uninstall your packages, and perform an audit to find security flaws in your packages.

      Prerequisites

      To complete this tutorial, you will need:

      Step 1 — Creating a package.json File

      We begin this tutorial by setting up the example project—a fictional Node.js locator module that gets the user’s IP address and returns the country of origin. You will not be coding the module in this tutorial. However, the packages you manage would be relevant if you were developing it.

      First, you will create a package.json file to store useful metadata about the project and help you manage the project’s dependent Node.js modules. As the suffix suggests, this is a JSON (JavaScript Object Notation) file. JSON is a standard format used for sharing, based on JavaScript objects and consisting of data stored as key-value pairs. If you would like to learn more about JSON, read our Introduction to JSON article.

      Since a package.json file contains numerous properties, it can be cumbersome to create manually, without copy and pasting a template from somewhere else. To make things easier, npm provides the init command. This is an interactive command that asks you a series of questions and creates a package.json file based on your answers.

      Using the init Command

      First, set up a project so you can practice managing modules. In your shell, create a new folder called locator:

      Then move into the new folder:

      Now, initialize the interactive prompt by entering:

      Note: If your code will use Git for version control, create the Git repository first and then run npm init. The command automatically understands that it is in a Git-enabled folder. If a Git remote is set, it automatically fills out the repository, bugs, and homepage fields for your package.json file. If you initialized the repo after creating the package.json file, you will have to add this information in yourself. For more on Git version control, see our Introduction to Git: Installation, Usage, and Branches series.

      You will receive the following output:

      Output
      This utility will walk you through creating a package.json file.
It only covers the most common items, and tries to guess sensible defaults.

See `npm help json` for definitive documentation on these fields
and exactly what they do.

Use `npm install <pkg>` afterwards to install a package and
save it as a dependency in the package.json file.

Press ^C at any time to quit.
package name: (locator)

      You will first be prompted for the name of your new project. By default, the command assumes it’s the name of the folder you’re in. Default values for each property are shown in parentheses (). Since the default value for name will work for this tutorial, press ENTER to accept it.

      The next value to enter is version. Along with the name, this field is required if your project will be shared with others in the npm package repository.

      Note: Node.js packages are expected to follow the Semantic Versioning (semver) guide. Therefore, the first number will be the MAJOR version number that only changes when the API changes. The second number will be the MINOR version that changes when features are added. The last number will be the PATCH version that changes when bugs are fixed.

      Press ENTER so the default version is accepted.

      The next field is description—a useful string to explain what your Node.js module does. Our fictional locator project would get the user’s IP address and return the country of origin. A fitting description would be Finds the country of origin of the incoming request, so type in something like this and press ENTER. The description is very useful when people are searching for your module.

      The following prompt will ask you for the entry point. If someone installs and requires your module, what you set in the entry point will be the first part of your program that is loaded. The value needs to be the relative location of a JavaScript file, and will be added to the main property of the package.json. Press ENTER to keep the default value.

      Note: Most modules have an index.js file as the main point of entry. This is the default value for a package.json’s main property, which is the point of entry for npm modules. If there is no package.json, Node.js will try to load index.js by default.

      Next, you’ll be asked for a test command, an executable script or command to run your project tests. In many popular Node.js modules, tests are written and executed with Mocha, Jest, Jasmine, or other test frameworks. Since testing is beyond the scope of this article, leave this option empty for now, and press ENTER to move on.

      The init command will then ask for the project’s GitHub Repository. You won’t use this in this example, so leave it empty as well.

      After the repository prompt, the command asks for keywords. This property is an array of strings with useful terms that people can use to find your repository. It’s best to have a small set of words that are really relevant to your project, so that searching can be more targeted. List these keywords as a string with commas separating each value. For this sample project, type ip,geo,country at the prompt. The finished package.json will have three items in the array for keywords.

      The next field in the prompt is author. This is useful for users of your module who want to get in contact with you. For example, if someone discovers an exploit in your module, they can use this to report the problem so that you can fix it. The author field is a string in the following format: "Name <Email> (Website)". For example, "Sammy <[email protected]_domain> (https://your_domain)" is a valid author. The email and website data are optional—a valid author could just be a name. Add your contact details as an author and confirm with ENTER.

      Finally, you’ll be prompted for the license. This determines the legal permissions and limitations users will have while using your module. Many Node.js modules are open source, so npm sets the default to ISC.

      At this point, you would review your licensing options and decide what’s best for your project. For more information on different types of open source licenses, see this license list from the Open Source Initiative. If you do not want to provide a license for a private repository, you can type UNLICENSED at the prompt. For this sample, use the default ISC license, and press ENTER to finish this process.

      The init command will now display the package.json file it’s going to create. It will look similar to this:

      Output
      About to write to /home/sammy/locator/package.json:

{
  "name": "locator",
  "version": "1.0.0",
  "description": "Finds the country of origin of the incoming request",
  "main": "index.js",
  "scripts": {
    "test": "echo "Error: no test specified" && exit 1"
  },
  "keywords": [
    "ip",
    "geo",
    "country"
  ],
  "author": "Sammy <sammy@your_domain> (https://your_domain)",
  "license": "ISC"
}


Is this OK? (yes)

      Once the information matches what you see here, press ENTER to complete this process and create the package.json file. With this file, you can keep a record of modules you install for your project.

      Now that you have your package.json file, you can test out installing modules in the next step.

      Step 2 — Installing Modules

      It is common in software development to use external libraries to perform ancillary tasks in projects. This allows the developer to focus on the business logic and create the application more quickly and efficiently.

      For example, if our sample locator module has to make an external API request to get geographical data, we could use an HTTP library to make that task easier. Since our main goal is to return pertinent geographical data to the user, we could install a package that makes HTTP requests easier for us instead of rewriting this code for ourselves, a task that is beyond the scope of our project.

      Let’s run through this example. In your locator application, you will use the axios library, which will help you make HTTP requests. Install it by entering the following in your shell:

      You begin this command with npm install, which will install the package (for brevity you can use npm i). You then list the packages that you want installed, separated by a space. In this case, this is axios. Finally, you end the command with the optional --save parameter, which specifies that axios will be saved as a project dependency.

      When the library is installed, you will see output similar to the following:

      Output
      ...
+ [email protected]
added 5 packages from 8 contributors and audited 5 packages in 0.764s
found 0 vulnerabilities

      Now, open the package.json file, using a text editor of your choice. This tutorial will use nano:

      You’ll see a new property, as highlighted in the following:

      locator/package.json

      {
  "name": "locator",
  "version": "1.0.0",
  "description": "Finds the country of origin of the incoming request",
  "main": "index.js",
  "scripts": {
    "test": "echo "Error: no test specified" && exit 1"
  },
  "keywords": [
    "ip",
    "geo",
    "country"
  ],
  "author": "Sammy [email protected]_domain (https://your_domain)",
  "license": "ISC",
  "dependencies": {
    "axios": "^0.19.0"
  }
}

      The --save option told npm to update the package.json with the module and version that was just installed. This is great, as other developers working on your projects can easily see what external dependencies are needed.

      Note: You may have noticed the ^ before the version number for the axios dependency. Recall that semantic versioning consists of three digits: MAJOR, MINOR, and PATCH. The ^ symbol signifies that any higher MINOR or PATCH version would satisfy this version constraint. If you see ~ at the beginning of a version number, then only higher PATCH versions satisfy the constraint.

      When you are finished reviewing package.json, exit the file.

      Development Dependencies

      Packages that are used for the development of a project but not for building or running it in production are called development dependencies. They are not necessary for your module or application to work in production, but may be helpful while writing the code.

      For example, it’s common for developers to use code linters to ensure their code follows best practices and to keep the style consistent. While this is useful for development, this only adds to the size of the distributable without providing a tangible benefit when deployed in production.

      Install a linter as a development dependency for your project. Try this out in your shell:

      In this command, you used the --save-dev flag. This will save eslint as a dependency that is only needed for development. Notice also that you added @6.0.0 to your dependency name. When modules are updated, they are tagged with a version. The @ tells npm to look for a specific tag of the module you are installing. Without a specified tag, npm installs the latest tagged version. Open package.json again:

      This will show the following:

      locator/package.json

      {
  "name": "locator",
  "version": "1.0.0",
  "description": "Finds the country of origin of the incoming request",
  "main": "index.js",
  "scripts": {
    "test": "echo "Error: no test specified" && exit 1"
  },
  "keywords": [
    "ip",
    "geo",
    "country"
  ],
  "author": "Sammy [email protected]_domain (https://your_domain)",
  "license": "ISC",
  "dependencies": {
    "axios": "^0.19.0"
  },
  "devDependencies": {
    "eslint": "^6.0.0"
  }
}

      eslint has been saved as a devDependencies, along with the version number you specified earlier. Exit package.json.

      Automatically Generated Files: node_modules and package-lock.json

      When you first install a package to a Node.js project, npm automatically creates the node_modules folder to store the modules needed for your project and the package-lock.json file that you examined earlier.

      Confirm these are in your working directory. In your shell, type ls and press ENTER. You will observe the following output:

      Output
      node_modules    package.json    package-lock.json

      The node_modules folder contains every installed dependency for your project. In most cases, you should not commit this folder into your version controlled repository. As you install more dependencies, the size of this folder will quickly grow. Furthermore, the package-lock.json file keeps a record of the exact versions installed in a more succinct way, so including node_modules is not necessary.

      While the package.json file lists dependencies that tell us the suitable versions that should be installed for the project, the package-lock.json file keeps track of all changes in package.json or node_modules and tells us the exact version of the package installed. You usually commit this to your version controlled repository instead of node_modules, as it’s a cleaner representation of all your dependencies.

      Installing from package.json

      With your package.json and package-lock.json files, you can quickly set up the same project dependencies before you start development on a new project. To demonstrate this, move up a level in your directory tree and create a new folder named cloned_locator in the same directory level as locator:

      • cd ..

      • mkdir cloned_locator

      Move into your new directory:

      Now copy the package.json and package-lock.json files from locator to cloned_locator:

      • cp ../locator/package.json ../locator/package-lock.json .

      To install the required modules for this project, type:

      npm will check for a package-lock.json file to install the modules. If no lock file is available, it would read from the package.json file to determine the installations. It is usually quicker to install from package-lock.json, since the lock file contains the exact version of modules and their dependencies, meaning npm does not have to spend time figuring out a suitable version to install.

      When deploying to production, you may want to skip the development dependencies. Recall that development dependencies are stored in the devDependencies section of package.json, and have no impact on the running of your app. When installing modules as part of the CI/CD process to deploy your application, omit the dev dependencies by running:

      The --production flag ignores the devDependencies section during installation. For now, stick with your development build.

      Before moving to the next section, return to the locator folder:

      Global Installations

      So far, you have been installing npm modules for the locator project. npm also allows you to install packages globally. This means that the package is available to your user in the wider system, like any other shell command. This ability is useful for the many Node.js modules that are CLI tools.

      For example, you may want to blog about the locator project that you’re currently working on. To do so, you can use a library like Hexo to create and manage your static website blog. Install the Hexo CLI globally like this:

      To install a package globally, you append the -g flag to the command.

      Note: If you get a permission error trying to install this package globally, your system may require super user privileges to run the command. Try again with sudo npm i hexo-cli -g.

      Test that the package was successfully installed by typing:

      You will see output similar to:

      Output
      hexo-cli: 2.0.0
os: Linux 4.15.0-64-generic linux x64
http_parser: 2.7.1
node: 10.14.0
v8: 7.6.303.29-node.16
uv: 1.31.0
zlib: 1.2.11
ares: 1.15.0
modules: 72
nghttp2: 1.39.2
openssl: 1.1.1c
brotli: 1.0.7
napi: 4
llhttp: 1.1.4
icu: 64.2
unicode: 12.1
cldr: 35.1
tz: 2019a

      So far, you have learned how to install modules with npm. You can install packages to a project locally, either as a production or development dependency. You can also install packages based on pre-existing package.json or package-lock.json files, allowing you to develop with the same dependencies as your peers. Finally, you can use the -g flag to install packages globally, so you can access them regardless of whether you’re in a Node.js project or not.

      Now that you can install modules, in the next section you will practice techniques to administer your dependencies.

      Step 3 — Managing Modules

      A complete package manager can do a lot more than install modules. npm has over 20 commands relating to dependency management available. In this step, you will:

      • List modules you have installed.
      • Update modules to a more recent version.
      • Uninstall modules you no longer need.
      • Perform a security audit on your modules to find and fix security flaws.

      While these examples will be done in your locator folder, all of these commands can be run globally by appending the -g flag at the end of them, exactly like you did when installing globally.

      Listing Modules

      If you would like to know which modules are installed in a project, it would be easier to use the list or ls command instead of reading the package.json directly. To do this, enter:

      You will see output like this:

      Output
      ├─┬ [email protected]
│ ├─┬ [email protected]
│ │ └─┬ [email protected]
│ │   └── [email protected]
│ └── [email protected]
└─┬ [email protected]
  ├─┬ @babel/[email protected]
  │ └─┬ @babel/[email protected]
  │   ├── [email protected] deduped
  │   ├── [email protected] deduped
  │   └── [email protected]
  ├─┬ [email protected]
  │ ├── [email protected]
  │ ├── [email protected]
  │ ├── [email protected]
  │ └─┬ [email protected]
...

      By default, ls shows the entire dependency tree—the modules your project depends on and the modules that your dependencies depend on. This can be a bit unwieldy if you want a high-level overview of what’s installed.

      To only print the modules you installed without their dependencies, enter the following in your shell:

      Your output will be:

      Output
      ├── [email protected]
└── [email protected]

      The --depth option allows you to specify what level of the dependency tree you want to see. When it’s 0, you only see your top level dependencies.

      Updating Modules

      It is a good practice to keep your npm modules up to date. This improves your likelihood of getting the latest security fixes for a module. Use the outdated command to check if any modules can be updated:

      You will get output like the following:

      Output
      Package  Current  Wanted  Latest  Location
eslint     6.0.0   6.7.1   6.7.1  locator

      This command first lists the Package that’s installed and the Current version. The Wanted column shows which version satisfies your version requirement in package.json. The Latest column shows the most recent version of the module that was published.

      The Location column states where in the dependency tree the package is located. The outdated command has the --depth flag like ls. By default, the depth is 0.

      It seems that you can update eslint to a more recent version. Use the update or up command like this:

      The output of the command will contain the version installed:

      Output
      npm WARN [email protected] No repository field.

+ eslint@6.7.1
added 7 packages from 3 contributors, removed 5 packages, updated 19 packages, moved 1 package and audited 184 packages in 5.818s
found 0 vulnerabilities

      If you wanted to update all modules at once, then you would enter:

      Uninstalling Modules

      The npm uninstall command can remove modules from your projects. This means the module will no longer be installed in the node_modules folder, nor will it be seen in your package.json and package-lock.json files.

      Removing dependencies from a project is a normal activity in the software development lifecycle. A dependency may not solve the problem as advertised, or may not provide a satisfactory development experience. In these cases, it may better to uninstall the dependency and build your own module.

      Imagine that axios does not provide the development experience you would have liked for making HTTP requests. Uninstall axios with the uninstall or un command by entering:

      Your output will be similar to:

      Output
      npm WARN [email protected] No repository field.

removed 5 packages and audited 176 packages in 1.488s
found 0 vulnerabilities

      It doesn’t explicitly say that axios was removed. To verify that it was uninstalled, list the dependencies once again:

      Now, we only see that eslint is installed:

      Output
      └── eslint@6.7.1

      This shows that you have successfully uninstalled the axios package.

      Auditing Modules

      npm provides an audit command to highlight potential security risks in your dependencies. To see the audit in action, install an outdated version of the request module by running the following:

      When you install this outdated version of request, you’ll notice output similar to the following:

      Output
      + [email protected]
added 54 packages from 49 contributors and audited 243 packages in 7.26s
found 6 moderate severity vulnerabilities
  run `npm audit fix` to fix them, or `npm audit` for details

      npm is telling you that you have vulnerabilities in your dependencies. To get more details, audit your entire project with:

      The audit command shows tables of output highlighting security flaws:

      Output
                             === npm audit security report ===

# Run  npm install [email protected]  to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ Memory Exposure                                              │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ tunnel-agent                                                 │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ request                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ request > tunnel-agent                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/598                             │
└───────────────┴──────────────────────────────────────────────────────────────┘

# Run  npm update request --depth 1  to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ Remote Memory Exposure                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ request                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ request                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ request                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/309                             │
└───────────────┴──────────────────────────────────────────────────────────────┘
...

      You can see the path of the vulnerability, and sometimes npm offers ways for you to fix it. You can run the update command as suggested, or you can run the fix subcommand of audit. In your shell, enter:

      You will see similar output to:

      Output
      + [email protected]
added 19 packages from 24 contributors, removed 32 packages and updated 12 packages in 6.223s
fixed 2 of 6 vulnerabilities in 243 scanned packages
  4 vulnerabilities required manual review and could not be updated

      npm was able to safely update two of the packages, decreasing your vulnerabilities by the same amount. However, you still have four vulnerabilities in your dependencies. The audit fix command does not always fix every problem. Although a version of a module may have a security vulnerability, if you update it to a version with a different API then it could break code higher up in the dependency tree.

      You can use the --force parameter to ensure the vulnerabilities are gone, like this:

      As mentioned before, this is not recommended unless you are sure that it won’t break functionality.

      Conclusion

      In this tutorial, you went through various exercises to demonstrate how Node.js modules are organized into packages, and how these packages are managed by npm. In a Node.js project, you used npm packages as dependencies by creating and maintaining a package.json file—a record of your project’s metadata, including what modules you installed. You also used the npm CLI tool to install, update, and remove modules, in addition to listing the dependency tree for your projects and checking and updating modules that are outdated.

      In the future, leveraging existing code by using modules will speed up development time, as you don’t have to repeat functionality. You will also be able to create your own npm modules, and these will in turn will be managed by others via npm commands. As for next steps, experiment with what you learned in this tutorial by installing and testing the variety of packages out there. See what the ecosystem provides to make problem solving easier. For example, you could try out TypeScript, a superset of JavaScript, or turn your website into mobile apps with Cordova. If you’d like to learn more about Node.js, see our other Node.js tutorials.



      Source link

      Como Escalar Automaticamente suas Cargas de Trabalho no Kubernetes da DigitalOcean


      Introdução

      Ao trabalhar com uma aplicação criada no Kubernetes, os desenvolvedores frequentemente precisam provisionar pods adicionais para lidar com períodos de pico de tráfego ou aumento da carga de processamento. Por padrão, provisionar esses pods adicionais é uma etapa manual; o desenvolvedor deve alterar o número de réplicas desejadas no objeto do deployment para contar com o aumento do tráfego e alterá-lo novamente quando os pods adicionais não forem mais necessários. Essa dependência da intervenção manual pode não ser o ideal em muitos cenários. Por exemplo, sua carga de trabalho pode atingir o horário de pico no meio da noite, quando ninguém está acordado para escalar os pods, ou seu site pode receber um aumento inesperado no tráfego quando uma resposta manual não seria rápida o suficiente para lidar com a carga. Nessas situações, a abordagem mais eficiente e menos sujeita a erros é automatizar o escalonamento dos seus clusters com o Horizontal Pod Autoscaler (HPA).

      Usando informações do Metrics Server, o HPA detectará aumento no uso de recursos e responderá escalando sua carga de trabalho para você. Isso é especialmente útil nas arquiteturas de microsserviço e dará ao cluster Kubernetes a capacidade de escalar seu deployment com base em métricas como a utilização da CPU. Quando combinado como o DigitalOcean Kubernetes (DOKS), uma oferta de Kubernetes gerenciada que fornece aos desenvolvedores uma plataforma para fazer o deploy de aplicações containerizadas, o uso do HPA pode criar uma infraestrutura automatizada que se ajusta rapidamente às mudanças no tráfego e na carga.

      Nota: Ao considerar a possibilidade de usar o autoscaling para sua carga de trabalho, lembre-se de que o autoscaling funciona melhor para aplicativos sem estado ou stateless, especialmente aqueles capazes de ter várias instâncias da aplicação em execução e aceitando tráfego em paralelo. Esse paralelismo é importante porque o principal objetivo do autoscaling é distribuir dinamicamente a carga de trabalho de uma aplicação por várias instâncias no cluster Kubernetes para garantir que sua aplicação tenha os recursos necessários para atender o tráfego de maneira ágil e estável, sem sobrecarregar nenhuma instância única.

      Um exemplo de carga de trabalho que não apresenta esse paralelismo é o autoscaling de banco de dados. A configuração do autoscaling para um banco de dados seria muito mais complexa, pois você precisaria considerar race conditions, problemas com a integridade dos dados, sincronização de dados e adições e remoções constantes de membros do cluster de banco de dados. Por razões como essas, não recomendamos o uso da estratégia de autoscaling deste tutorial para bancos de dados.

      Neste tutorial você vai configurar um deployment de exemplo do Nginx no DOKS que pode auto escalar horizontalmente para dar conta do aumento da carga de CPU. Você conseguirá isso ao fazer o deploy do Metrics Server em seu cluster para reunir métricas de pod para o HPA usar para determinar quando escalar.

      Pré-requisitos

      Antes de começar este guia, você precisará do seguinte:

      • Um cluster Kubernetes na DigitalOcean com sua conexão configurada como padrão kubectl. As instruções sobre como configurar o kubectl são mostradas no passo Connect to your Cluster quando você cria seu cluster. Para criar um cluster Kubernetes na DigitalOcean, consulte Kubernetes Quickstart.

      • O gerenciador de pacotes Helm instalado em sua máquina local e o Tiller instalado em seu cluster. Para fazer isso, execute os passos 1 e 2 do tutorial How To Install Software on Kubernetes Clusters with the Helm Package Manager

      Passo 1 — Criando um Deployment de Teste

      Para mostrar o efeito do HPA, você primeiro fará o deploy de uma aplicação que você utilizará para fazer autoscale. Este tutorial usa uma imagem Nginx Docker padrão como um deployment porque ela é totalmente capaz de operar em paralelo, é amplamente usada no Kubernetes com ferramentas como o Nginx Ingress Controller, e é leve para configurar. Esse deployment do Nginx servirá uma página estática Welcome to Nginx!, que vem por padrão na imagem base. Se você já possui um deployment que gostaria de escalar, sinta-se à vontade para usá-lo e pule este passo.

      Crie o deployment de exemplo usando a imagem base do Nginx executando o seguinte comando. Você pode substituir o nome web se desejar atribuir um nome diferente ao seu deployment:

      • kubectl create deployment web --image=nginx:latest

      A flag --image=nginx:latest criará o deployment a partir da versão mais recente da imagem base do Nginx.

      Após alguns segundos, seu pod web será lançado. Para ver este pod, execute o seguinte comando, que mostrará os pods em execução no namespace atual:

      Isso lhe dará uma saída semelhante à seguinte:

      Output
      NAME                                                   READY   STATUS             RESTARTS   AGE
web-84d7787df5-btf9h                                   1/1     Running            0          11s

      Observe que há apenas um pod deployado originalmente. Depois que o autoscaling é acionado, mais pods serão criados automaticamente.

      Agora você tem um deployment básico em funcionamento no cluster. Este é o deployment que você irá configurar para o autoscaling. Seu próximo passo é configurar esse deployment para definir suas solicitações de recursos e limites.

      Passo 2 — Definindo Limites e Solicitações de CPU em seu Deployment

      Neste passo, você irá definir solicitações e limites no uso da CPU para seu deployment. Limites ou Limits no Kubernetes são definidos no deployment para descrever a quantidade máxima de recursos (CPU ou Memória) que o pod pode usar. Solicitações ou Requests são definidas no deployment para descrever quanto desse recurso é necessário em um node para que esse node seja considerado como um node válido para escalonamento. Por exemplo, se seu servidor web tivesse uma solicitação de memória definida em 1 GB, apenas os nodes com pelo menos 1 GB de memória livre seriam considerados para escalonamento. Para o autoscaling, é necessário definir esses limites e solicitações, pois o HPA precisará ter essas informações ao tomar decisões de escalonamento e provisionamento.

      Para definir solicitações e limites, você precisará fazer alterações no deployment que você acabou de criar. Este tutorial usará o seguinte comando kubectl edit para modificar a configuração do objeto API armazenada no cluster. O comando kubectl edit abrirá o editor definido por suas variáveis de ambiente KUBE_EDITOR ou EDITOR, ou cairá de volta no vi para Linux ou notepad para Windows por padrão.

      Edite seu deployment:

      • kubectl edit deployment web

      Você verá a configuração para o deployment. Agora você pode definir limites de recursos e solicitações especificadas para o uso de CPU do seu deployment. Esses limites definem a linha de base de quanto de cada recurso um pod deste deployment pode usar individualmente. Definir isso dará ao HPA um quadro de referência para saber se um pod está sendo sobrecarregado. Por exemplo, se você espera que seu pod tenha um limit superior de 100 milicores de CPU e o pod esteja usando 95 milicores atualmente, a HPA saberá que está com 95% da capacidade. Sem fornecer esse limite de 100 milicores, o HPA não pode decifrar a capacidade total do pod.

      Podemos definir os limites e solicitações na seção resources:

      Deployment Configuration File

      . . .
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: web
    spec:
      containers:
      - image: nginx:latest
        imagePullPolicy: Always
        name: nginx
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
status:
  availableReplicas: 1
. . .

      Para este tutorial, você definirá requests para CPU como 100m e memória para 250Mi. Esses valores são apenas para fins de demonstração; cada carga de trabalho é diferente, portanto, esses valores podem não fazer sentido para outras cargas de trabalho. Como regra geral, esses valores devem ser definidos no máximo que um pod dessa carga de trabalho deve usar. Recomenda-se o monitoramento da aplicação e a coleta de dados de uso de recursos sobre o desempenho em períodos de baixa e de pico para ajudar a determinar esses valores. Esses valores também podem ser ajustados e alterados a qualquer momento, assim você sempre pode voltar e otimizar seu deployment posteriormente.

      Vá em frente e insira as seguintes linhas destacadas na seção resources do seu container Nginx:

      Deployment Configuration File

      . . .
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: web
    spec:
      containers:
      - image: nginx:latest
        imagePullPolicy: Always
        name: nginx
        resources:
          limits:
            cpu: 300m
          requests:
            cpu: 100m
            memory: 250Mi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
status:
  availableReplicas: 1
. . .

      Depois de inserir essas linhas, salve e saia do arquivo. Se houver um problema com a sintaxe, o kubectl irá reabrir o arquivo para você com um erro publicado para que você obtenha mais informações.

      Agora que você definiu seus limites e solicitações, você precisa garantir que suas métricas sejam reunidas para que o HPA possa monitorar e aderir corretamente a esses limites. Para fazer isso, você irá configurar um serviço para reunir as métricas de CPU. Para este tutorial, você usará o projeto Metrics Server para coletar essas métricas, que você instalará com um chart do Helm.

      Passo 3 — Instalando o Metrics Server

      Agora você instalará o Kubernetes Metric Server. Esse é o servidor que extrai as métricas do pod, que reunirá as métricas que o HPA usará para decidir se o autoscaling é necessário.

      Para instalar o Metrics Server usando o Helm, execute o seguinte comando:

      • helm install stable/metrics-server --name metrics-server

      Isso instalará a versão estável mais recente do Metrics Server. A flag --name nomeia este release como metrics-server.

      Depois de aguardar a inicialização deste pod, tente usar o comando kubectl top pod para exibir as métricas do seu pod:

      Este comando tem como objetivo fornecer uma visão em nível de pod do uso de recursos em seu cluster, mas devido à maneira como o DOKS lida com o DNS, esse comando retornará um erro neste momento:

      Output
      Error: Metrics not available for pod

Error from server (ServiceUnavailable): the server is currently unable to handle the request (get pods.metrics.k8s.io)

      Esse erro ocorre porque os nodes DOKS não criam um registro DNS para eles mesmos e, como o Metrics Server entra em contato com os nodes por meio de seus nomes de host, os nomes de host não são resolvidos corretamente. Para corrigir esse problema, altere a maneira como o Metrics Server se comunica com os nodes adicionando flags de runtime ao container do Metrics Server usando o seguinte comando:

      • kubectl edit deployment metrics-server

      Você estará adicionando uma flag na seção command.

      metrics-server Configuration File

      . . .
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: metrics-server
        release: metrics-server
    spec:
      affinity: {}
      containers:
      - command:
        - /metrics-server
        - --cert-dir=/tmp
        - --logtostderr
        - --secure-port=8443
        image: gcr.io/google_containers/metrics-server-amd64:v0.3.4
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /healthz
. . .

      A flag que você está adicionando é --kubelet-preferred-address-types=InternalIP. Essa flag informa ao metrics server para contatar os nodes usando seu internalIP em oposição ao nome do host. Você pode usar essa flag como uma solução alternativa para se comunicar com os nodes por meio de endereços IP internos.

      Adicione também a flag --metric-resolution para alterar a taxa padrão na qual o Metrics Server extrai as métricas. Para este tutorial, configuraremos o Metrics Server para realizar pontos de coletas de dados a cada 60s, mas se você quiser mais dados de métricas, poderá solicitar ao Metrics Server que extraia as métricas a cada 10s ou 20s. Isso lhe fornecerá mais pontos de dados de uso de recursos por período de tempo. Sinta-se livre para ajustar esta resolução para atender às suas necessidades.

      Adicione as seguintes linhas destacadas ao arquivo:

      metrics-server Configuration File

      . . .
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: metrics-server
        release: metrics-server
    spec:
      affinity: {}
      containers:
      - command:
        - /metrics-server
        - --cert-dir=/tmp
        - --logtostderr
        - --secure-port=8443
        - --metric-resolution=60s
        - --kubelet-preferred-address-types=InternalIP
        image: gcr.io/google_containers/metrics-server-amd64:v0.3.4
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /healthz
. . .

      Após a adição da flag, salve e saia do seu editor.

      Para verificar se o Metrics Server está em execução, use o kubectl top pod após alguns minutos. Como antes, este comando nos fornecerá o uso de recursos em um nível de pod. Dessa vez, um Metrics Server funcionando permitirá que você veja as métricas em cada pod:

      Isso fornecerá a seguinte saída, com o seu pod do Metrics Server em execução:

      Output
      NAME                             CPU(cores)   MEMORY(bytes)
metrics-server-db745fcd5-v8gv6   3m           12Mi
web-555db5bf6b-f7btr             0m           2Mi

      Agora você tem um Metrics Server funcional e pode visualizar e monitorar o uso de recursos de pods em seu cluster. Em seguida, você irá configurar o HPA para monitorar esses dados e reagir a períodos de alto uso da CPU.

      Passo 4 — Criando e Validando o Autoscaler Horizontal de Pod

      Por fim, é hora de criar o Horizontal Pod Autoscaler (HPA) para seu deployment. O HPA é o objeto real do Kubernetes que verifica rotineiramente os dados de uso de CPU coletados do Metrics Server e escala seu deployment com base nos limites que você definiu no Passo 2.

      Crie o HPA usando o comando kubectl autoscale:

      • kubectl autoscale deployment web  --max=4 --cpu-percent=80

      Este comando cria o HPA para seu deployment web. Ele também usa a flag --max para definir o máximo de réplicas nas quais web pode ser escalado, o que, neste caso, você define como 4.

      A flag --cpu-percent informa ao HPA em qual porcentagem de uso do limite que você definiu no Passo 2 você deseja que o autoscale ocorra. Isso também usa os requests para ajudar a provisionar os pods escalados para um node que possa acomodar a alocação inicial de recursos. Neste exemplo, se o limite que você definiu para o seu deployment no Passo 1 fosse 100 milicores (100m), esse comando dispararia um autoscale assim que o pod atingisse 80m no uso médio da CPU. Isso permitiria que o deployment fosse escalado automaticamente antes de estourar seus recursos de CPU.

      Agora que seu deployment pode ser escalado automaticamente, é hora de testar isso.

      Para validar, você irá gerar uma carga que colocará seu cluster acima do seu limite e assistirá o autoscaler assumir o controle. Para começar, abra um segundo terminal para observar os pods provisionados no momento e atualizar a lista de pods a cada 2 segundos. Para fazer isso, use o comando watch neste segundo terminal:

      O comando watch emite o comando dado como argumento continuamente, exibindo a saída no seu terminal. A duração entre repetições pode ser configurada mais finamente com a flag -n. Para os fins deste tutorial, a configuração padrão de dois segundos será suficiente.

      O terminal agora exibirá a saída do kubectl top pods inicialmente e, a cada 2 segundos, atualizará a saída que esse comando gera, que será semelhante a esta:

      Output
      Every 2.0s: kubectl top pods                                                                                                                                 

NAME                              CPU(cores)   MEMORY(bytes)
metrics-server-6fd5457684-7kqtz   3m           15Mi
web-7476bb659d-q5bjv              0m           2Mi

      Anote o número de pods atualmente deployados para o web.

      Volte ao seu terminal original. Agora você abrirá um terminal dentro do seu pod web atual usando kubectl exec e criará uma carga artificial. Você pode fazer isso entrando no pod e instalando o stress CLI tool.

      Digite seu pod usando kubectl exec, substituindo o nome do pod realçado pelo nome do seu pod web:

      • kubectl exec -it web-f765fd676-s9729 /bin/bash

      Este comando é muito semelhante em conceito ao de usar ssh para efetuar login em outra máquina. O /bin/bash estabelece um shell bash no seu pod.

      Em seguida, no shell bash dentro do seu pod, atualize os metadados do repositório e instale o pacote stress.

      • apt update; apt-get install -y stress

      Nota: Para containers baseados no CentOS, isso seria assim:

      Em seguida, gere alguma carga de CPU no seu pod usando o comando stress e deixe-o executar:

      Agora, volte ao seu comando watch no segundo terminal. Aguarde alguns minutos para o Metrics Server reunir dados de CPU acima do limite definido pelo HPA. Observe que as métricas por padrão são coletadas na taxa que você definir como --metric-resolution ao configurar o metrics server. Pode demorar um minuto para que as métricas de uso sejam atualizadas.

      Após cerca de dois minutos, você verá pods adicionais web subindo:

      Output
      Every 2.0s: kubectl top pods                                                                                                                                 

NAME                             CPU(cores)   MEMORY(bytes)
metrics-server-db745fcd5-v8gv6   6m           16Mi
web-555db5bf6b-ck98q             0m           2Mi
web-555db5bf6b-f7btr             494m         21Mi
web-555db5bf6b-h5cbx             0m           1Mi
web-555db5bf6b-pvh9f             0m           2Mi

      Agora você pode ver que o HPA provisionou novos pods com base na carga de CPU coletada pelo Metrics Server. Quando estiver satisfeito com esta validação, use CTRL+C para interromper o comando stress no seu primeiro terminal e então, saia do shell bash do seu pod.

      Conclusão

      Neste artigo, você criou um deployment que será escalado automaticamente com base na carga de CPU. Você adicionou limites de recursos e solicitações de CPU ao seu deployment, instalou e configurou o Metrics Server em seu cluster por meio do uso do Helm e criou um HPA para tomar decisões de escalabilidade.

      Esse foi um deployment de demonstração tanto do Metrics Server quanto do HPA. Agora você pode ajustar a configuração para se adequar aos seus casos de uso específicos. Certifique-se de verificar a documentação do Kubernetes HPA para ajuda e informação sobre requests e limits. Além disso, confira o Projeto Metrics Server para ver todas as configurações ajustáveis que podem ser aplicadas ao seu caso de uso.

      Se você gostaria de fazer mais com o Kubernetes, visite nossa Página da Comunidade Kubernetes ou explore nosso Serviço Gerenciado de Kubernetes.



      Source link

      Como usar o Git para Gerenciar seu Projeto de Redação


      Introdução

      O controle de versão não é apenas para código. É para qualquer coisa que você queira acompanhar, incluindo conteúdo. Usar o Git para gerenciar o seu próximo projeto de redação permite a você exibir vários rascunhos ao mesmo tempo, ver diferenças entre esses rascunhos e até reverter para uma versão anterior. E se você estiver confortável com isso, poderá compartilhar seu trabalho com outras pessoas no GitHub ou em outros repositórios centrais do Git.

      Neste tutorial, você usará o Git para gerenciar um pequeno documento Markdown. Você armazenará uma versão inicial, fará o commit ou confirmação dela, fará alterações, visualizará a diferença entre essas alterações e revisará a versão anterior. Quando terminar, você terá um fluxo de trabalho que poderá aplicar aos seus próprios projetos de redação.

      Pré-requisitos

      Passo 1 — Criando um Espaço de Trabalho para Seu Projeto de Redação

      Para gerenciar suas alterações, você criará um repositório Git local. Um repositório Git vive dentro de um diretório existente; portanto, comece criando um novo diretório para o seu artigo:

      Mude para o novo diretório artigo:

      O comando git init cria um novo repositório Git vazio no diretório atual. Execute esse comando agora:

      Você verá a seguinte saída que confirma que seu repositório foi criado:

      Output
      Initialized empty Git repository in /Users/sammy/artigo/.git/

      O arquivo .gitignore permite que você informe ao Git que alguns arquivos devem ser ignorados. Você pode usar isso para ignorar arquivos temporários que seu editor de texto possa criar ou arquivos de sistemas operacionais. No macOS, por exemplo, o aplicativo Finder cria arquivos .DS_Store em diretórios. Crie um arquivo .gitignore que os ignore:

      Adicione as seguintes linhas ao arquivo:

      .gitignore

      # Ignore Finder files
.DS_store

      A primeira linha é um comentário, que o ajudará a identificar o que você está ignorando no futuro. A segunda linha especifica o arquivo a ser ignorado.

      Salve o arquivo e saia do editor.

      À medida que você descobrir mais arquivos que deseja ignorar, abra o arquivo .gitignore e adicione uma nova linha para cada arquivo ou diretório que deseja ignorar.

      Agora que seu repositório está configurado, você pode começar a trabalhar.

      Passo 2 — Salvando Seu Rascunho Inicial

      O Git só conhece os arquivos que você conta para ele. Só porque um arquivo existe no diretório que contém o repositório não significa que o Git irá rastrear suas alterações. Você precisa adicionar o arquivo ao repositório e confirmar as alterações.

      Crie um novo arquivo Markdown chamado artigo.md:

      Adicione algum texto ao arquivo:

      artigo.md

      # Como Usar o Git para Gerenciar seu Projeto de Redação

### Introdução

O controle de versão não é apenas para código. É para qualquer coisa que você queira acompanhar, incluindo conteúdo. Usar o [Git](https://git-scm.com) para gerenciar o seu próximo projeto de redação permite a você exibir vários rascunhos ao mesmo tempo, ver diferenças entre esses rascunhos e até reverter para uma versão anterior. E se você estiver confortável com isso, poderá compartilhar seu trabalho com outras pessoas no GitHub ou em outros repositórios centrais do Git. 

Neste tutorial, você usará o Git para gerenciar um pequeno documento Markdown. Você armazenará uma versão inicial, fará o commit ou confirmação dela, fará alterações, visualizará a diferença entre essas alterações e revisará a versão anterior. Quando terminar, você terá um fluxo de trabalho que poderá aplicar aos seus próprios projetos de redação.

      Salve as alterações e saia do editor.

      O comando git status mostrará o estado do seu repositório. Ele mostrará quais arquivos precisam ser adicionados para que o Git possa rastreá-los. Execute este comando:

      Você verá esta saída:

      Output
      On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    .gitignore
    artigo.md

nothing added to commit but untracked files present (use "git add" to track)

      Na saída, a seção Untracked files mostra os arquivos que o Git não está vendo. Esses arquivos precisam ser adicionados ao repositório para que o Git possa observá-los quanto a alterações. Use o comando git add para fazer isso:

      • git add .gitignore

      • git add artigo.md

      Agora execute o git status para verificar se esses arquivos foram adicionados:

      Output
      On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

    new file:   .gitignore
    new file:   artigo.md

      Agora os dois arquivos estão listados na seção Changes to be committed, ou seja, alterações a serem confirmadas. O Git sabe sobre eles, mas ainda não criou um instantâneo do trabalho. Use o comando git commit para fazer isso.

      Quando você cria um novo commit, você precisa fornecer uma mensagem de commit. Uma boa mensagem de commit fala sobre quais são as suas alterações. Quando você está trabalhando com outras pessoas, quanto mais detalhadas forem suas mensagens de commit, melhor.

      Use o comando git commit para confirmar suas alterações:

      • git commit -m "Adicionar arquivo gitignore e versão inicial do artigo"

      A saída do comando mostra que os arquivos foram confirmados:

      Output
      [master (root-commit) 95fed84] Adicionar arquivo gitignore e versão inicial do artigo
 2 files changed, 9 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 artigo.md

      Use o comando git status para ver o estado do repositório:

      A saída mostra que não há alterações que precisam ser adicionadas ou confirmadas.

      Output
      On branch master
nothing to commit, working tree clean

      Agora vamos ver como trabalhar com alterações.

      Passo 3 — Salvando Revisões

      Você adicionou sua versão inicial do artigo. Agora você adicionará mais texto para poder ver como gerenciar alterações com o Git.

      Abra o artigo no seu editor:

      Adicione um pouco mais de texto ao final do arquivo:

      ## Pré-requisitos

* Git instalado em seu computador local. O tutorial [How to Contribute to Open Source: Getting Started with Git](https://www.digitalocean.com/community/tutorials/how-to-contribute-to-open-source-getting-started-with-git) orienta você na instalação do Git e cobre algumas informações básicas que você pode achar úteis.

      Salve o artigo

      Use o comando git status para ver onde estão as coisas no seu repositório:

      A saída mostra que há alterações:

      Output
      On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   artigo.md

no changes added to commit (use "git add" and/or "git commit -a")

      Como esperado, o arquivo artigo.md sofreu alterações.

      Use git diff para ver o quais são elas:

      A saída mostra as linhas que você adicionou:

      diff --git a/artigo.md b/artigo.md
index 77b081c..ef6c301 100644
--- a/artigo.md
+++ b/artigo.md
@@ -5,3 +5,7 @@
 O controle de versão não é apenas para código. É para qualquer coisa que você queira acompanhar, incluindo conteúdo. Usar o [Git](https://git-scm.com) para gerenciar o seu próximo projeto de redação permite a você exibir vários rascunhos ao mesmo tempo, ver diferenças entre esses rascunhos e até reverter para uma versão anterior. E se você estiver confortável com isso, poderá compartilhar seu trabalho com outras pessoas no GitHub ou em outros repositórios centrais do Git. 

 Neste tutorial, você usará o Git para gerenciar um pequeno documento Markdown. Você armazenará uma versão inicial, fará o commit ou confirmação dela, fará alterações, visualizará a diferença entre essas alterações e revisará a versão anterior. Quando terminar, você terá um fluxo de trabalho que poderá aplicar aos seus próprios projetos de redação.
+
+## Pré-requisitos
+
+* Git instalado em seu computador local. O tutorial [How to Contribute to Open Source: Getting Started with Git](https://www.digitalocean.com/community/tutorials/how-to-contribute-to-open-source-getting-started-with-git) orienta você na instalação do Git e cobre algumas informações básicas que você pode achar úteis.

      Na saída, linhas começando com um sinal de mais (+) são linhas que você adicionou. As linhas removidas apareceriam com um sinal de menos (-). As linhas inalteradas não teriam nenhum desses caracteres na frente.

      Usar git diff e git status é uma maneira útil de ver o que você mudou. Você também pode salvar o diff em um arquivo para visualizá-lo mais tarde com o seguinte comando:

      • git diff artigo.md > artigo_diff.diff

      O uso da extensão .diff ajudará seu editor de texto a aplicar o realce apropriado da sintaxe.

      Salvar as alterações no seu repositório é um processo de duas etapas. Primeiro, adicione o arquivo artigo.md novamente e depois faça o commit. O Git quer que você diga a ele explicitamente quais arquivos estão em cada commit, portanto, mesmo que você tenha adicionado o arquivo antes, você deve adicioná-lo novamente. Note que a saída do comando git status lembra você disso.

      Adicione o arquivo e faça o commit das alterações, fornecendo uma mensagem de commit:

      • git add artigo.md

      • git commit -m "adicionada seção de pré-requisitos"

      A saída verifica que o commit funcionou:

      Output
      [master 1fbfc21] adicionada seção de pré-requisitos
 1 file changed, 4 insertions(+)

      Use git status para ver o status do seu repositório. Você verá que não há mais nada a fazer.

      Output
      On branch master
nothing to commit, working tree clean

      Continue esse processo enquanto revisa seu artigo. Faça as alterações, verifique-as, adicione o arquivo e faça o commit das alterações com uma mensagem detalhada. Faça commit de suas alterações com a frequência que desejar. Você pode realizar um commit depois de concluir cada rascunho ou antes de fazer uma grande reformulação da estrutura do seu artigo.

      Se você enviar um rascunho de um documento para outra pessoa e ela fizer alterações, pegue a cópia e substitua o arquivo pelo dela. Em seguida, use git diff para ver rapidamente as alterações que ela fez. O Git verá as alterações, tenha você digitado diretamente ou substituido o arquivo por um que você baixou da web, e-mail ou outro local.

      Agora, vamos analisar o gerenciamento das versões do seu artigo.

      Passo 4 — Gerenciando Alterações

      Às vezes, é útil olhar para uma versão anterior de um documento. Sempre que você usou o git commit, você forneceu uma mensagem útil que resume o que você fez.

      O comando git log mostra o histórico de commit do seu repositório. Toda mudança que você fez commit tem uma entrada no log.

      Output
      commit 1fbfc2173f3cec0741e0a6b21803fbd0be511bc4
Author: Sammy Shark <[email protected]>
Date:   Thu Sep 19 16:35:41 2019 -0500

    adicionada seção de pré-requisitos

commit 95fed849b0205c49eda994fff91ec03642d59c79
Author: Sammy Shark <[email protected]>
Date:   Thu Sep 19 16:32:34 2019 -0500

    Adicionar arquivo gitignore e versão inicial do artigo

      Cada commit possui um identificador específico. Você usa esse número para referenciar as alterações de um commit específico. Você só precisa dos primeiros caracteres do identificador. O comando git log --oneline fornece a você uma versão condensada do log com identificadores mais curtos:

      Output
      1fbfc21 adicionada seção de pré-requisitos
95fed84 Adicionar arquivo gitignore e versão inicial do artigo

      Para visualizar a versão inicial do seu arquivo, use git show e o identificador do commit. Os identificadores no seu repositório serão diferentes dos que estão nesses exemplos.

      • git show 95fed84 artigo.md

      A saída mostra os detalhes do commit, bem como as alterações que ocorreram durante esse commit:

      Output
      commit 95fed849b0205c49eda994fff91ec03642d59c79
Author: Sammy Shark <[email protected]>
Date:   Thu Sep 19 16:32:34 2019 -0500

    Adicionar arquivo gitignore e versão inicial do artigo

diff --git a/artigo.md b/artigo.md
new file mode 100644
index 0000000..77b081c
--- /dev/null
+++ b/artigo.md
@@ -0,0 +1,7 @@
+# Como Usar o Git para Gerenciar seu Projeto de Redação
+
+### Introdução
+
+O controle de versão não é apenas para código. É para qualquer coisa que você queira acompanhar, incluindo conteúdo. Usar o [Git](https://git-scm.com) para gerenciar o seu próximo projeto de redação permite a você exibir vários rascunhos ao mesmo tempo, ver diferenças entre esses rascunhos e até reverter para uma versão anterior. E se você estiver confortável com isso, poderá compartilhar seu trabalho com outras pessoas no GitHub ou em outros repositórios centrais do Git.
+
+Neste tutorial, você usará o Git para gerenciar um pequeno documento Markdown. Você armazenará uma versão inicial, fará o commit ou confirmação dela, fará alterações, visualizará a diferença entre essas alterações e revisará a versão anterior. Quando terminar, você terá um fluxo de trabalho que poderá aplicar aos seus próprios projetos de redação.

      Para ver o próprio arquivo, modifique o comando levemente. Em vez de um espaço entre o identificador do commit e o arquivo, substitua por :./ assim:

      • git show 95fed84:./artigo.md

      Você verá o conteúdo desse arquivo, nessa revisão:

      Output
      ### Introdução

O controle de versão não é apenas para código. É para qualquer coisa que você queira acompanhar, incluindo conteúdo. Usar o [Git](https://git-scm.com) para gerenciar o seu próximo projeto de redação permite a você exibir vários rascunhos ao mesmo tempo, ver diferenças entre esses rascunhos e até reverter para uma versão anterior. E se você estiver confortável com isso, poderá compartilhar seu trabalho com outras pessoas no GitHub ou em outros repositórios centrais do Git. 

Neste tutorial, você usará o Git para gerenciar um pequeno documento Markdown. Você armazenará uma versão inicial, fará o commit ou confirmação dela, fará alterações, visualizará a diferença entre essas alterações e revisará a versão anterior. Quando terminar, você terá um fluxo de trabalho que poderá aplicar aos seus próprios projetos de redação.

      Você pode salvar essa saída em um arquivo se precisar disso para outra coisa:

      • git show 95fed84:./artigo.md > old_artigo.md

      À medida que você fizer mais alterações, seu log aumentará e você poderá revisar todas as alterações feitas no seu artigo ao longo do tempo.

      Conclusão

      Neste tutorial, você usou um repositório Git local para rastrear as alterações no seu projeto de redação. Você pode usar essa abordagem para gerenciar artigos individuais, todas as postagens do seu blog ou até mesmo seu próximo romance. E se você enviar seu repositório para o GitHub, poderá convidar outras pessoas para ajudá-lo a editar seu trabalho.



      Source link

      Forgot Your Password ?