One place for hosting & domains

      Como Configurar um Banco de Dados Remoto para Otimizar o Desempenho do Site com o MySQL no Ubuntu 18.04


      Introdução

      À medida que sua aplicação ou site cresce, pode chegar um momento em que você superou a configuração atual do seu servidor. Se você estiver hospedando o seu servidor web e o back-end do banco de dados na mesma máquina, pode ser uma boa ideia separar essas duas funções para que cada uma possa operar em seu próprio hardware e compartilhar a carga de responder às solicitações dos visitantes.

      Neste guia, veremos como configurar um servidor de banco de dados MySQL remoto ao qual sua aplicação web pode se conectar. Usaremos o WordPress como exemplo para ter algo para trabalhar, mas a técnica é amplamente aplicável a qualquer aplicação suportada pelo MySQL.

      Pré-requisitos

      Antes de iniciar este tutorial, você precisará de:

      • Dois servidores Ubuntu 18.04. Cada um deles deve ter um usuário não-root com privilégios sudo e um firewall UFW habilitado, conforme descrito em nosso tutorial de Configuração Inicial de servidor com Ubuntu 18.04. Um desses servidores hospedará seu back-end MySQL e, ao longo deste guia, o chamaremos de servidor de banco de dados. O outro se conectará ao seu servidor de banco de dados remotamente e atuará como seu servidor web; da mesma forma, iremos nos referir a ele como servidor web ao longo deste guia.
      • Nginx e PHP instalado em seu servidor web. Nosso tutorial How To Install Linux, Nginx, MySQL, PHP (LEMP stack) in Ubuntu 18.04 o guiará no processo, mas observe que você deve pular o Passo 2 deste tutorial, que se concentra na instalação do MySQL, pois você instalará o MySQL no seu servidor de banco de dados.
      • MySQL instalado em seu servidor de banco de dados. Siga o tutorial Como Instalar o MySQL no Ubuntu 18.04 para configurar isso.
      • Opcionalmente (mas altamente recomendado), certificados TLS/SSL da Let’s Encrypt instalados em seu servidor web. Você precisará comprar um nome de domínio e ter registros DNS configurados para seu servidor, mas os certificados em si são gratuitos. Nosso guia Como Proteger o Nginx com o Let’s Encrypt no Ubuntu 18.04 lhe mostrará como obter esses certificados.

      Passo 1 — Configurando o MySQL para Escutar Conexões Remotas

      Ter os dados armazenados em um servidor separado é uma boa maneira de expandir elegantemente após atingir o limite máximo de desempenho de uma configuração de uma única máquina. Ela também fornece a estrutura básica necessária para balancear a carga e expandir sua infraestrutura ainda mais posteriormente. Após instalar o MySQL, seguindo o tutorial de pré-requisitos, você precisará alterar alguns valores de configuração para permitir conexões a partir de outros computadores.

      A maioria das mudanças na configuração do servidor MySQL pode ser feita no arquivo mysqld.cnf, que é armazenado no diretório /etc/mysql/mysql.conf.d/ por padrão. Abra este arquivo em seu servidor de banco de dados com privilégios de root em seu editor preferido. Aqui, iremos usar o nano:

      • sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

      Este arquivo é dividido em seções indicadas por labels entre colchetes ([ e ]). Encontre a seção com o label mysqld:

      /etc/mysql/mysql.conf.d/mysqld.cnf

      . . .
      [mysqld]
      . . .
      

      Nesta seção, procure um parâmetro chamado bind-address. Isso informa ao software do banco de dados em qual endereço de rede escutar as conexões.

      Por padrão, isso está definido como 127.0.0.1, significando que o MySQL está configurado para escutar apenas conexões locais. Você precisa alterar isso para fazer referência a um endereço IP externo onde seu servidor pode ser acessado.

      Se os dois servidores estiverem em um datacenter com recursos de rede privada, use o IP da rede privada do seu servidor de banco de dados. Caso contrário, você pode usar seu endereço IP público:

      /etc/mysql/mysql.conf.d/mysqld.cnf

      [mysqld]
      . . .
      bind-address = ip_do_servidor_de_banco_de_dados
      

      Como você se conectará ao seu banco de dados pela Internet, é recomendável que você exija conexões criptografadas para manter seus dados seguros. Se você não criptografar sua conexão MySQL, qualquer pessoa na rede poderá fazer sniff por informações confidenciais entre seus servidores web e de banco de dados. Para criptografar conexões MySQL, adicione a seguinte linha após a linha bind-address que você acabou de atualizar:

      /etc/mysql/mysql.conf.d/mysqld.cnf

      [mysqld]
      . . .
      require_secure_transport = on
      . . .
      

      Salve e feche o arquivo quando terminar. Se você estiver usando nano, faça isso pressionando CTRL+X, Y e, em seguida, ENTER.

      Para que as conexões SSL funcionem, você precisará criar algumas chaves e certificados. O MySQL vem com um comando que os configura automaticamente. Execute o seguinte comando, que cria os arquivos necessários. Ele também os torna legíveis pelo servidor MySQL, especificando o UID do usuário mysql:

      • sudo mysql_ssl_rsa_setup --uid=mysql

      Para forçar o MySQL a atualizar sua configuração e ler as novas informações de SSL, reinicie o banco de dados:

      • sudo systemctl restart mysql

      Para confirmar que o servidor agora está escutando na interface externa, execute o seguinte comando netstat:

      • sudo netstat -plunt | grep mysqld

      Output

      tcp 0 0 ip_do_servidor_de_banco_de_dados:3306 0.0.0.0:* LISTEN 27328/mysqld

      O netstat imprime estatísticas sobre o sistema de rede do seu servidor. Esta saída nos mostra que um processo chamado mysqld está anexado ao ip_do_servidor_de_banco_de_dados na porta 3306, a porta padrão do MySQL, confirmando que o servidor está escutando na interface apropriada.

      Em seguida, abra essa porta no firewall para permitir o tráfego através dela:

      Essas são todas as alterações de configuração que você precisa fazer no MySQL. A seguir, veremos como configurar um banco de dados e alguns perfis de usuário, um dos quais você usará para acessar o servidor remotamente.

      Passo 2 — Configurando um Banco de Dados para o WordPress e Credenciais Remotas

      Embora o próprio MySQL agora esteja escutando em um endereço IP externo, atualmente não há usuários ou bancos de dados habilitados para controle remoto configurados. Vamos criar um banco de dados para o WordPress e um par de usuários que possam acessá-lo.

      Comece conectando-se ao MySQL como o usuário root do MySQL:

      Nota: Se você tiver a autenticação por senha ativada, conforme descrito no Passo 3 do pré-requisito do tutorial do MySQL, você precisará usar o seguinte comando para acessar o shell do MySQL:

      Depois de executar este comando, você será solicitado a fornecer sua senha de root do MySQL e, após inseri-la, receberá um novo prompt mysql>.

      No prompt do MySQL, crie um banco de dados que o WordPress usará. Pode ser útil atribuir a esse banco de dados um nome reconhecível para que você possa identificá-lo facilmente mais tarde. Aqui, vamos chamá-lo de wordpress:

      • CREATE DATABASE wordpress;

      Agora que você criou seu banco de dados, você precisará criar um par de usuários. Criaremos um usuário somente local e um usuário remoto vinculado ao endereço IP do servidor web.

      Primeiro, crie seu usuário local, wpuser, e faça com que esta conta corresponda apenas às tentativas de conexão local usando localhost na declaração:

      • CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'senha';

      Em seguida, conceda a esta conta acesso total ao banco de dados wordpress:

      • GRANT ALL PRIVILEGES ON wordpress.* TO 'wpuser'@'localhost';

      Agora, esse usuário pode executar qualquer operação no banco de dados do WordPress, mas essa conta não pode ser usada remotamente, pois corresponde apenas às conexões da máquina local. Com isso em mente, crie uma conta complementar que corresponda às conexões exclusivamente do seu servidor web. Para isso, você precisará do endereço IP do seu servidor web.

      Observe que você deve usar um endereço IP que utilize a mesma rede que você configurou no seu arquivo mysqld.cnf. Isso significa que, se você especificou um IP de rede privada no arquivo mysqld.cnf, precisará incluir o IP privado do seu servidor web nos dois comandos a seguir. Se você configurou o MySQL para usar a internet pública, você deve fazer isso corresponder ao endereço IP público do servidor web.

      • CREATE USER 'remotewpuser'@'ip_do_servidor_web' IDENTIFIED BY 'senha';

      Depois de criar sua conta remota, conceda a ela os mesmos privilégios que o usuário local:

      • GRANT ALL PRIVILEGES ON wordpress.* TO 'remotewpuser'@'ip_do_servidor_web';

      Por fim, atualize os privilégios para que o MySQL saiba começar a usá-los:

      Então saia do prompt do MySQL digitando:

      Agora que você configurou um novo banco de dados e um usuário habilitado remotamente, você pode testar se consegue se conectar ao banco de dados a partir do seu servidor web.

      Passo 3 — Testando Conexões Remotas e Locais

      Antes de continuar, é melhor verificar se você pode se conectar ao seu banco de dados tanto a partir da máquina local — seu servidor de banco de dados — quanto pelo seu servidor web.

      Primeiro, teste a conexão local a partir do seu servidor de banco de dados tentando fazer login com sua nova conta:

      Quando solicitado, digite a senha que você configurou para esta conta.

      Se você receber um prompt do MySQL, então a conexão local foi bem-sucedida. Você pode sair novamente digitando:

      Em seguida, faça login no seu servidor web para testar as conexões remotas:

      • ssh sammy@ip_do_servidor_web

      Você precisará instalar algumas ferramentas de cliente para MySQL em seu servidor web para acessar o banco de dados remoto. Primeiro, atualize o cache de pacotes local se você não tiver feito isso recentemente:

      Em seguida, instale os utilitários de cliente do MySQL:

      • sudo apt install mysql-client

      Depois disso, conecte-se ao seu servidor de banco de dados usando a seguinte sintaxe:

      • mysql -u remotewpuser -h ip_do_servidor_de_banco_de_dados -p

      Novamente, você deve certificar-se que está usando o endereço IP correto para o servidor de banco de dados. Se você configurou o MySQL para escutar na rede privada, digite o IP da rede privada do seu banco de dados. Caso contrário, digite o endereço IP público do seu servidor de banco de dados.

      Você será solicitado a inserir a senha da sua conta remotewpuser. Depois de inseri-la, e se tudo estiver funcionando conforme o esperado, você verá o prompt do MySQL. Verifique se a conexão está usando SSL com o seguinte comando:

      Se a conexão realmente estiver usando SSL, a linha SSL: indicará isso, como mostrado aqui:

      Output

      -------------- mysql Ver 14.14 Distrib 5.7.18, for Linux (x86_64) using EditLine wrapper Connection id: 52 Current database: Current user: remotewpuser@203.0.113.111 SSL: Cipher in use is DHE-RSA-AES256-SHA Current pager: stdout Using outfile: '' Using delimiter: ; Server version: 5.7.18-0ubuntu0.16.04.1 (Ubuntu) Protocol version: 10 Connection: 203.0.113.111 via TCP/IP Server characterset: latin1 Db characterset: latin1 Client characterset: utf8 Conn. characterset: utf8 TCP port: 3306 Uptime: 3 hours 43 min 40 sec Threads: 1 Questions: 1858 Slow queries: 0 Opens: 276 Flush tables: 1 Open tables: 184 Queries per second avg: 0.138 --------------

      Depois de verificar que você pode se conectar remotamente, vá em frente e saia do prompt:

      Com isso, você verificou o acesso local e o acesso a partir do servidor web, mas não verificou se outras conexões serão recusadas. Para uma verificação adicional, tente fazer o mesmo em um terceiro servidor para o qual você não configurou uma conta de usuário específica para garantir que esse outro servidor não tenha o acesso concedido.

      Observe que antes de executar o seguinte comando para tentar a conexão, talvez seja necessário instalar os utilitários de cliente do MySQL, como você fez acima:

      • mysql -u wordpressuser -h ip_do_servidor_de_banco_de_dados -p

      Isso não deve ser concluído com êxito e deve gerar um erro semelhante a este:

      Output

      ERROR 1130 (HY000): Host '203.0.113.12' is not allowed to connect to this MySQL server

      Isso é esperado, já que você não criou um usuário do MySQL que tem permissão para se conectar a partir deste servidor, e também é desejado, uma vez que você quer ter certeza de que seu servidor de banco de dados negará o acesso de usuários não autorizados ao seu servidor do MySQL.

      Após testar com êxito sua conexão remota, você pode instalar o WordPress em seu servidor web.

      Passo 4 — Instalando o WordPress

      Para demonstrar os recursos do seu novo servidor MySQL com capacidade remota, passaremos pelo processo de instalação e configuração do WordPress — o popular sistema de gerenciamento de conteúdo — em seu servidor web. Isso exigirá que você baixe e extraia o software, configure suas informações de conexão e então execute a instalação baseada em web do WordPress.

      No seu servidor web, faça o download da versão mais recente do WordPress para o seu diretório home:

      • cd ~
      • curl -O https://wordpress.org/latest.tar.gz

      Extraia os arquivos, que criarão um diretório chamado wordpress no seu diretório home:

      O WordPress inclui um arquivo de configuração de exemplo que usaremos como ponto de partida. Faça uma cópia deste arquivo, removendo -sample do nome do arquivo para que ele seja carregado pelo WordPress:

      • cp ~/wordpress/wp-config-sample.php ~/wordpress/wp-config.php

      Quando você abre o arquivo, sua primeira abordagem será ajustar algumas chaves secretas para fornecer mais segurança à sua instalação. O WordPress fornece um gerador seguro para esses valores, para que você não precise criar bons valores por conta própria. Eles são usados apenas internamente, portanto, não prejudicará a usabilidade ter valores complexos e seguros aqui.

      Para obter valores seguros do gerador de chave secreta do WordPress, digite:

      • curl -s https://api.wordpress.org/secret-key/1.1/salt/

      Isso imprimirá algumas chaves na sua saída. Você as adicionará momentaneamente ao seu arquivo wp-config.php:

      Atenção! É importante que você solicite seus próprios valores únicos sempre. Não copie os valores mostrados aqui!

      Output

      define('AUTH_KEY', 'L4|2Yh(giOtMLHg3#] DO NOT COPY THESE VALUES %G00o|te^5YG@)'); define('SECURE_AUTH_KEY', 'DCs-k+MwB90/-E(=!/ DO NOT COPY THESE VALUES +WBzDq:7U[#Wn9'); define('LOGGED_IN_KEY', '*0kP!|VS.K=;#fPMlO DO NOT COPY THESE VALUES +&[%8xF*,18c @'); define('NONCE_KEY', 'fmFPF?UJi&(j-{8=$- DO NOT COPY THESE VALUES CCZ?Q+_~1ZU~;G'); define('AUTH_SALT', '@qA7f}2utTEFNdnbEa DO NOT COPY THESE VALUES t}Vw+8=K%20s=a'); define('SECURE_AUTH_SALT', '%BW6s+d:7K?-`C%zw4 DO NOT COPY THESE VALUES 70U}PO1ejW+7|8'); define('LOGGED_IN_SALT', '-l>F:-dbcWof%4kKmj DO NOT COPY THESE VALUES 8Ypslin3~d|wLD'); define('NONCE_SALT', '4J(<`4&&F (WiK9K#] DO NOT COPY THESE VALUES ^ZikS`es#Fo:V6');

      Copie a saída que você recebeu para a área de transferência e abra o arquivo de configuração no seu editor de texto:

      • nano ~/wordpress/wp-config.php

      Encontre a seção que contém os valores fictícios para essas configurações. Será algo parecido com isto:

      /wordpress/wp-config.php

      . . .
      define('AUTH_KEY',         'put your unique phrase here');
      define('SECURE_AUTH_KEY',  'put your unique phrase here');
      define('LOGGED_IN_KEY',    'put your unique phrase here');
      define('NONCE_KEY',        'put your unique phrase here');
      define('AUTH_SALT',        'put your unique phrase here');
      define('SECURE_AUTH_SALT', 'put your unique phrase here');
      define('LOGGED_IN_SALT',   'put your unique phrase here');
      define('NONCE_SALT',       'put your unique phrase here');
      . . .
      

      Exclua essas linhas e cole os valores que você copiou a partir da linha de comando.

      Em seguida, insira as informações de conexão para seu banco de dados remoto. Essas linhas de configuração estão na parte superior do arquivo, logo acima de onde você colou suas chaves. Lembre-se de usar o mesmo endereço IP que você usou no teste de banco de dados remoto anteriormente:

      /wordpress/wp-config.php

      . . .
      /** The name of the database for WordPress */
      define('DB_NAME', 'wordpress');
      
      /** MySQL database username */
      define('DB_USER', 'remotewpuser');
      
      /** MySQL database password */
      define('DB_PASSWORD', 'password');
      
      /** MySQL hostname */
      define('DB_HOST', 'db_server_ip');
      . . .
      

      E, finalmente, em qualquer lugar do arquivo, adicione a seguinte linha que diz ao WordPress para usar uma conexão SSL para o nosso banco de dados MySQL:

      /wordpress/wp-config.php

      define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL);
      

      Salve e feche o arquivo.

      Em seguida, copie os arquivos e diretórios encontrados no diretório ~/wordpress para a raiz de documentos do Nginx. Observe que este comando inclui a flag -a para garantir que todas as permissões existentes sejam transferidas:

      • sudo cp -a ~/wordpress/* /var/www/html

      Depois disso, a única coisa a fazer é modificar a propriedade do arquivo. Altere a propriedade de todos os arquivos na raiz de documentos para www-data, o usuário padrão do servidor web do Ubuntu:

      • sudo chown -R www-data:www-data /var/www/html

      Com isso, o WordPress está instalado e você está pronto para executar sua rotina de configuração baseada em web.

      Passo 5 — Configurando o WordPress Através da Interface Web

      O WordPress possui um processo de configuração baseado na web. Conforme você avança, ele fará algumas perguntas e instalará todas as tabelas necessárias no seu banco de dados. Aqui, abordaremos as etapas iniciais da configuração do WordPress, que você pode usar como ponto de partida para criar seu próprio site personalizado que usa um back-end de banco de dados remoto.

      Navegue até o nome de domínio (ou endereço IP público) associado ao seu servidor web:

      http://example.com
      

      Você verá uma tela de seleção de idioma para o instalador do WordPress. Selecione o idioma apropriado e clique na tela principal de instalação:

      WordPress install screen

      Depois de enviar suas informações, você precisará fazer login na interface de administração do WordPress usando a conta que você acabou de criar. Você será direcionado para um painel onde poderá personalizar seu novo site WordPress.

      Conclusão

      Ao seguir este tutorial, você configurou um banco de dados MySQL para aceitar conexões protegidas por SSL a partir de uma instalação remota do WordPress. Os comandos e técnicas usados neste guia são aplicáveis a qualquer aplicação web escrita em qualquer linguagem de programação, mas os detalhes específicos da implementação serão diferentes. Consulte a documentação do banco de dados da aplicação ou linguagem para obter mais informações.



      Source link

      Host a Static Site using Linode Object Storage


      Updated by Linode

      Contributed by

      Linode

      Note

      Object Storage is currently in a closed early access Beta, and you may not have access to Object Storage through the Cloud Manager or other tools. To gain access to the Early Access Program (EAP), open up a Customer Support ticket noting that you’d like to be included in the program, or e-mail objbeta@linode.com – beta access is completely free.

      Additionally, because Object Storage is in Beta, there may be breaking changes to how you access and manage Object Storage. This guide will be updated to reflect these changes if and when they occur.

      Why Host a Static Site on Object Storage?

      Static site generators are a popular solution for creating simple, fast, flexible, and attractive websites that are easy to update. You can contribute new pages and content to a static site in two steps:

      1. First, write the content for your site’s new page using Markdown, an easy-to-learn and light-weight markup language.

      2. Then, tell your static site generator to compile your Markdown (along with other relevant assets, like CSS styling, images, and JavaScript) into static HTML files.

      The second compilation step only needs to happen once for each time that you update your content. This is in contrast with a dynamic website framework like WordPress or Drupal, which will reference a relational database and compile your HTML every time a visitor loads your site.

      Benefits of Hosting on Object Storage

      Traditionally, these static HTML files would be served by a web server (like NGINX or Apache) running on a Linode. Using Object Storage to host your static site files means you do not have to worry about maintaining your site’s infrastructure. It is no longer necessary to perform typical server maintenance tasks, like software upgrades, web server configuration, and security upkeep.

      Object Storage provides an HTTP REST gateway to objects, which means a unique URL over HTTP is available for every object. Once your static site is built, making it available publicly over the Internet is as easy uploading files to an Object Storage bucket.

      Object Storage Hosting Workflow

      At a high-level, the required steps to host a static site using Object Storage are:

      1. Install the static site generator of your choice to your local computer.

      2. Create the desired content and build the site (using your static site generator).

      3. Upload the static files to your Object Storage bucket to make the content publicly available over the Internet.

      This guide will use Hugo to demonstrate how to create a static site and host it on Linode Object Storage. However, there are many other static site generators to choose from–Jekyll and Gatsby are popular choices, and the general steps outlined in this guide could be adapted to them. For more information on choosing a static site generator, see the How to Choose a Static Site Generator guide.

      Before You Begin

      1. Read the How to Use Linode Object Storage guide to familiarize yourself with Object Storage on Linode. Specifically, be sure that you have:

        • Created your Object Storage access and secret keys.
        • Installed and configure the s3cmd tool.
      2. Install and configure Git on your local computer.

      Install the Hugo Static Site Generator

      Hugo is written in Go and is known for being extremely fast to compile sites, even very large ones. It is well-supported, well-documented, and has an active community. Some useful Hugo features include shortcodes, which are an easy way to include predefined templates inside of your Markdown, and built-in LiveReload web server, which allows you to preview your site changes locally as you make them.

      1. Install Hugo on your computer:

        macOS:

        Linux/Ubuntu:

        • Determine your Linux kernel’s architecture:

          uname -r
          

          Your output will resemble the following:

            
          4.9.0-8-amd64
          
          
        • Navigate to Hugo’s GitHub releases page and download the appropriate version for your platform. This example command downloads version 0.55, but a newer release may be available:

          wget https://github.com/gohugoio/hugo/releases/download/v0.55.0/hugo_0.55.0_Linux-64bit.deb
          
        • Install the package using dpkg:

          sudo dpkg -i hugo*.deb
          
      2. Verify that Hugo is installed. You should see output indicating your installed Hugo’s version number:

        hugo version
        

      Create a Hugo Site

      In this section, you will use the Hugo CLI (command line interface) to create your Hugo site, initialize a Hugo theme, and add content to your site. Hugo’s CLI provides several useful commands for common tasks needed to build, configure, and interact with your Hugo site.

      1. Create a new Hugo site on your local computer. This command will create a folder named example-site and scaffold Hugo’s directory structure inside it:

        hugo new site example-site
        
      2. Move into your Hugo site’s root directory:

        cd example-site
        

        Note

        All commands in this section of the guide should be issued from your site’s root directory.

      3. You will use Git to add a theme to your Hugo site’s directory. Initialize your Hugo site’s directory as a Git repository:

        git init
        
      4. Install the Ananke theme as a submodule of your Hugo site’s Git repository. Git submodules allow one Git repository to be stored as a subdirectory of another Git repository, while still being able to maintain each repository’s version control information separately. The Ananke theme’s repository will be located in the ~/example-site/themes/ananke directory of your Hugo site.

        git submodule add https://github.com/budparr/gohugo-theme-ananke.git themes/ananke
        

        Note

        Hugo has many available themes that can be installed as a submodule of your Hugo site’s directory.
      5. Add the theme to your Hugo site’s configuration file. The configuration file (config.toml) is located at the root of your Hugo site’s directory.

        echo 'theme = "ananke"' >> config.toml
        
      6. Create a new content file for your site. This command will generate a Markdown file with an auto-populated date and title:

        hugo new posts/my-first-post.md
        
      7. You should see a similar output. Note that the file is located in the content/posts/ directory of your Hugo site:

          
        /home/username/example-site/content/posts/my-first-post.md created
        
        
      8. Open the Markdown file in the text editor of your choice to begin modifying its content; you can copy and paste the example snippet into your file, which contains an updated front matter section at the top and some example Markdown body text.

        Set your desired value for title. Then, set the draft state to false and add your content below the --- in Markdown syntax, if desired:

        /home/username/example-site/content/posts/my-first-post.md
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        
        ---
        title: "My First Post"
        date: 2019-04-11T11:25:11-04:00
        draft: false
        ---
        
        # Host a Static Site on Linode Object Storage
        
        There are many benefits to using a static site generator. Here is a list of a few of them:
        
        - Run your own website without having to manage a Linode.
        - You don't need to worry about running a web server like Apache or NGINX.
        - Static website performance is typically very fast.
        - Use Git to version control your static website's content.


        About front matter

        Front matter is a collection of metadata about your content, and it is embedded at the top of your file within opening and closing --- delimiters.

        Front matter is a powerful Hugo feature that provides a mechanism for passing data that is attached to a specific piece of content to Hugo’s rendering engine. Hugo accepts front matter in TOML, YAML, and JSON formats. In the example snippet, there is YAML front matter for the title, date, and draft state of the Markdown file. These variables will be referenced and displayed by your Hugo theme.

      9. Once you have added your content, you can preview your changes by building and serving the site using Hugo’s built-in webserver:

        hugo server
        
      10. You will see a similar output:

          
        &nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp| EN
        +------------------+----+
          Pages&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp| 11
          Paginator pages&nbsp&nbsp&nbsp&nbsp|  0
          Non-page files&nbsp&nbsp&nbsp&nbsp&nbsp|  0
          Static files&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp|  3
          Processed images&nbsp&nbsp&nbsp|  0
          Aliases&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp|  1
          Sitemaps&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp|  1
          Cleaned&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp|  0
        
        Total in 7 ms
        Watching for changes in /home/username/example-site/{content,data,layouts,static,themes}
        Watching for config changes in /home/username/example-site/config.toml
        Serving pages from memory
        Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
        Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
        Press Ctrl+C to stop
        
        
      11. The output will provide a URL to preview your site. Copy and paste the URL into a browser to access the site. In the above example Hugo’s web server URL is http://localhost:1313/.

      12. When you are happy with your site’s content you can build your site:

        hugo -v
        

        Hugo will generate your site’s static HTML files and store them in a public directory that it will create inside your project. The static files that are generated by Hugo are the files that you will upload to your Object Storage bucket to make your site accessible via the Internet.

      13. View the contents of your site’s public directory:

        ls public
        

        Your output should resemble the following example. When you built the site, the Markdown file you created and edited in steps 6 and 7 was used to generate its corresponding static HTML file in the public/posts/my-first-post/index.html directory.

          
          404.html    categories  dist        images      index.html  index.xml   posts       sitemap.xml tags
            
        


        Track your Static Site Files with Git

        It’s not necessary to version control your site files in order to host them on Object Storage, but we still recommended that you do so:

        1. Display the state of your current working directory (root of your Hugo site):

          git status
          
        2. Stage all your files to be committed:

          git add -A
          
        3. Commit all your changes and add a meaningful commit message:

          git commit -m 'Add my first post.'
          

        Once you have used Git to track your local Hugo site files, you can easily push them to a remote Git repository, like GitHub or GitLab. Storing your static site files on a remote Git repository opens up many possibilities for collaboration and automating your static site’s deployment to Linode Object Storage. To learn more about Git, see the Getting Started with Git guide.

      Upload your Static Site to Linode Object Storage

      Before proceeding with this section ensure that you have already created your Object Storage access and secret keys and have installed the s3cmd tool.

      1. Create a new Object Storage bucket; prepend s3:// to the beginning of the bucket’s name:

        s3cmd mb s3://my-bucket
        

        Note

        Buckets names must be unique within the Object Storage cluster. You might find the bucket name my-bucket is already in use by another Linode customer, in which case you will need to choose a new bucket name.

      2. Initialize your Object Storage bucket as a website. You must tell your bucket which files to serve as the index page and the error page for your static site. This is done with the --ws-index and --ws-error options:

        s3cmd ws-create --ws-index=index.html --ws-error=404.html s3://my-bucket
        

        In our Hugo example, the site’s index file is index.html and the error file is 404.html. Whenever a user visits your static site’s URL, the Object Storage service will serve the index.html page. If a site visitor tries to access an invalid path, they will be presented with the 404.html page.

      3. The command will return the following message:

          
            Bucket 's3://my-bucket/': website configuration created.
              
        
      4. Display information about your Object Storage’s website configuration to obtain your site’s URL:

        s3cmd ws-info s3://my-bucket
        
      5. You should see a similar output. Be sure to take note of your Object Storage bucket’s URL:

          
              Bucket s3://my-bucket/: Website configuration
        Website endpoint: http://website-us-east-1.linodeobjects.com/
        Index document:   index.html
        Error document:   404.html
            
        

        Note

        The Linode Object Storage early access Beta provides SSL enabled by default. This means you can access your Object Storage bucket using https, as well.

      6. Use s3cmd’s sync command to upload the contents of your static site’s public directory to your Object Storage bucket. This step will make your site available publicly on the Internet. Ensure you are in your site’s root directory on your computer (e.g. /home/username/example-site):

        s3cmd --no-mime-magic --acl-public --delete-removed --delete-after sync public/ s3://my-bucket
        
        Option                          Description
        no-mime-magic Tells Object Storage not to use file signatures when guessing the object’s MIME-type.
        acl-public Sets the access level control of the objects to public.
        delete-removed Deletes any destination objects with no corresponding source file.
        delete-after Deletes destination files that are no longer found at the source after all files are uploaded to the bucket.
      7. Use a browser to navigate to your Object Storage bucket’s URL to view your Hugo site:

        Hugo Index Page

        Note

        It may take a minute or two after your s3cmd sync completes for the page to appear at your bucket’s website URL.

      8. If needed, you can continue to update your static site locally and upload any changes using s3cmd’s sync command from step 3 of this section.

      (Optional) Next Steps

      After uploading your static site to Linode Object Storage, you may want to use a custom domain for your site. To do this, you can add a CNAME entry to your domain’s DNS records that aliases it to your Object Storage bucket’s website URL. To learn about managing DNS records on Linode, see the DNS Manager and DNS Records: An Introduction guides.

      As noted before, it’s possible to trigger automatic deployments to the Object Storage service when you push new content updates to GitHub or GitLab. This is done by leveraging a CI/CD (continuous integration/continuous delivery) tool like Travis CI. Essentially, you would build your Hugo site within the Travis environment and then run the s3cmd sync command from it to your bucket.

      More Information

      You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

      Find answers, ask questions, and help others.

      This guide is published under a CC BY-ND 4.0 license.



      Source link

      Should I Switch Web Hosts? How to Know When It’s Time to Migrate Your Site


      When it comes to starting a website, web hosting is one of the most crucial yet most confusing aspects to tackle. With dozens of providers on the market, it can be hard to cut through the noise and figure out which one offers the best plan for you.

      Fortunately, several signs will make it clear when it’s time to move to a new host. While they’re not so pleasant to deal with in the moment, these issues may lead you to a better service provider that can help you boost your site’s success.

      In this post, we’ll discuss these signs and how to spot them on your website. Then we’ll explain how to migrate your site to a new web hosting platform. Let’s get started!

      Have a website? We’ll move it for you!

      Migrating to a new web hosting provider can be a pain. We’ll move your existing site within 48 hours without any interruption in service. Included FREE with any DreamPress plan.

      How to Know When It’s Time to Migrate (6 Tell-Tale Signs)

      It’s possible you’ve been experiencing problems with your website for a while now without really knowing why. In some cases, it may be that your web hosting provider isn’t a good fit for your website. These six signs will let you know it’s time to switch web hosts.

      1. You’re Experiencing More Downtime Than Usual

      Any time your website is unavailable to users, it’s considered ‘down.’ Even if your site is only unavailable for seconds at a time, it could cause serious problems. For starters, downtime makes your website appear unreliable and low-quality to both users and search engines.

      If your site is experiencing frequent outages, your users will come to find they can’t rely on it to be available when needed. The Google algorithm will account for this, and your search engine rankings will fall as well, hurting your site’s visibility.

      Plus, if your site generates revenue, you’ll be missing out on income every time your site has an outage. If your site is down often or for long periods of time, you could be losing hundreds or even thousands of dollars. When you’re running an online store, uptime truly affects your bottom line.

      Web hosting is one of the most common causes of website downtime, as there are many ways in which your server can impact your site’s availability, including:

      • The quality and reliability of your hosting equipment
      • The type of server your website is on, as shared servers tend to become overloaded more quickly than other types of servers.
      • Your host’s security features, since malicious attacks can lead to downtime.

      So, if you keep finding your website is down, there’s a fair chance your host may have something to do with it. Moving to a more reliable server is the best thing for your site in a situation like this.

      2. Your Website’s Loading Speed Is Slow

      Site speed is also key to Search Engine Optimization (SEO), users’ opinions of your site, and your conversion rate. It’s wise to test your site’s speed every once in a while using tools such as Google PageSpeed Insights and Pingdom to make sure your loading times are staying low and to fix any performance issues.

      Pingdom’s results screen.

      While a crowded server can certainly slow your loading times, your server’s location also plays a role in how fast your site delivers information to visitors. Servers located far away from end users aren’t able to serve them content as quickly.

      An easy way to determine if this is the case for your website is to use Pingdom to test your site speed from a variety of locations. If your site loads quickly from some places yet takes a long time to load in others, you’ll know server location is causing speed issues for users in those regions.

      If your host only has servers in one location and doesn’t offer a Content Delivery Network (CDN), it’s almost guaranteed that some portion of your users will experience less-than-ideal site speed. It may be worth looking into hosts with more or different locations, or ones offering a CDN.

      3. Customer Service Isn’t Helpful

      A solid relationship with your web host is priceless. For starters, there are going to be times when server-related errors occur on your site. In these instances, you’ll need to be able to get ahold of your host quickly to resolve the issue and get your site back up. Plus, you may sometimes have questions about billing or other account details.

      However, the best hosts also offer support in other areas of website management. For example, many hosts provide troubleshooting guidance for different types of errors on your website or support for platforms such as WordPress.

      If your host is difficult to get in touch with, provides inadequate solutions, or doesn’t offer support in areas directly related to your hosting account, consider switching to a new provider. While you may be able to get by without quality customer support, at some point, you’ll have to reach someone for help with a server-related problem, so you’ll want a reliable team at your back.

      4. You Need More Space Than Your Current Provider Can Offer

      Most websites start small and grow over time. Your current host may have been a great fit when you were first launching your site, but if your traffic levels have increased significantly, this may no longer be the case.

      As your site accumulates more recurring users, you’ll need a server that can handle more traffic as well as more and larger website files. Moving from shared hosting to a dedicated server can help, but switching hosts can often provide a greater benefit.

      Some providers specialize in shared or Virtual Private Network (VPN) hosting and may not offer dedicated servers. As such, if your site continues to grow, you’ll need a dedicated web hosting service at some point — so a switch may be inevitable.

      Other hosts may have dedicated servers available, but still not offer as much storage as you need. Ultimately, you’ll want to compare plans between companies to see which one offers the most space for the best price.

      5. It’s Getting Too Expensive to Stay With Your Current Host

      Web hosting is a recurring expense. It’s also sometimes the largest expense associated with running a website, especially for WordPress users working with a free Content Management System (CMS) and mainly free plugins and themes.

      It’s true that you often get what you pay for with hosting. However, there are also times when an expensive plan isn’t necessary. If your site is still small and not using the amount of server space you’re paying for, or if your current hosting plan comes with several features you never touch, you’re probably paying too much.

      There’s no sense in breaking the bank to host your website when there are plenty of affordable options available. For example, we offer high-quality managed WordPress hosting plans for as low as $16.95 per month.

      If you’re shelling out more money for web hosting than what your website brings in, you might want to consider downsizing or switching hosts to stay within your budget. Plus, it never hurts to pocket a little extra cash each month.

      6. Server Security Is Sub-Par

      As we mentioned earlier in this post, hosts are responsible for securing their servers. Not every provider is as diligent as they should be when it comes to security, and hackers will sometimes exploit weaknesses in your server to gain access to your site.

      This can be detrimental to your website for multiple reasons, including:

      • The loss of parts or all of your site due to a malicious attack that destroys key files and data.
      • Compromised user data, including sensitive information such as private records and credit card details.
      • Decreased credibility, as users will see your site as less reliable if it’s hacked.

      Investing in secure hosting is a smart move. Even if you have to pay a little extra or go through the trouble of migrating to a new host, you’ll save yourself a lot of trouble down the line.

      Some security features you may want to keep an eye out for are Secure Sockets Layer (SSL) certificates, malware scanning, and server firewalls. Of course, no matter how secure your server is, you should always follow security best practices for your site itself, too.

      How to Migrate Your Website to a New Hosting Provider

      If you’ve considered the signs mentioned above and determined you should switch hosting providers, you’ll need to migrate your website. This requires you to copy all your website’s files and move them to your new hosting account.

      Typically, the migration process is pretty involved. You’ll have to contact your current host, back up your site files, then use Secure File Transfer Protocol (SFTP) and a client such as FileZilla to connect to your new server and upload your files. You’ll also want to consider transferring your domain since there are benefits to keeping your domain registration and web hosting under one roof.

      As you might imagine, there are a lot of things that could go wrong during this process. For example, corrupted backups are always a possibility, and using SFTP still poses a risk to your site’s files as you could mistakenly delete some or all of them (we recommend users always have a recent backup of their site on hand).

      These things considered, it’s helpful if you can get an expert on board to migrate your site for you. Fortunately, if you’re a WordPress user and have decided to switch to DreamHost, our managed WordPress hosting plans include free website migration services.

      DreamHost’s WordPress migration services.

      We’ll handle moving your site at no extra cost. If you’d prefer one of our shared hosting plans or have a website built without using WordPress, never fear. You can still take advantage of our migration service for just $99.

      Our migration experts will get your site moved to your new hosting account within 48 hours of your request. You’ll also avoid downtime altogether, so you don’t have to worry about negatively impacting your users’ experience while you move your site and get acquainted with the DreamHost control panel.

      Looking for a New Hosting Provider?

      We make moving easy. Our hassle-free, high-performance WordPress hosting includes a FREE professional migration service ($99 savings)!

      Switching Web Hosts

      Hosting can be one of the most confusing aspects of owning a website. With so many options to choose from, it can be difficult to know if your web hosting provider is the best one available for your needs.

      If you’ve noticed these issues on your website and have decided it’s time for a change, consider checking out our DreamPress hosting plans. Our managed WordPress hosting service will provide you with the speed, support, and security your WordPress site needs. Plus, you’ll be able to use our site migration services for free.



      Source link