VARNISH - LEARN VCL

When using Varnish, you will most likely hear VCL and especially the /etc/varnish/default.vcl file. So what is VCL? What is the meaning of the code in that? In this article I will explain to you general understanding of VCL to learn more on the Varnish Documentation. Let's also say that most of the code in VCL is to detect and compare values ​​so use regex (regular expression) a lot so this is a good chance you should learn about regular expressions.

What is VCL in Varnish?
VCL in Varnish is the acronym for the Varnish Configuration Language, and by the name you probably know what it is. VCL is structured by subroutines and each subroutine has a function when the code within each subroutine matches the directives of the hits sent to the server. It sounds abstract, so imagine VCL having some subroutines in VCL such as program that returns client data, program receives client data ... and in each program we will write code to regulate Control it to work as desired. For example, you can specify that Varnish does not send caches to queries that access a website carrying a cookie (eg, the cookie wordpress_logged_in of user queries that are logged into WordPres). Although VCL is simple but extremely powerful because you can build a subroutine yourself in addition to using the available subroutines of Varnish. Here is an example of a code that uses the vcl_recv subroutine to customize the receiving of data from the backend server into Varnish.
This also means that all the code in the default.vcl file must be in a subroutine and a subroutine can not be re-used twice in the same file.
What will the site do without any VCL code?

If your default.vcl file does not contain any VCL content outside of the backend server line to declare the backend's connection port, all of your pages are cached and automatically cleaned after 2 minutes.
Structure of a VCL segment The code structure of VCL is very simple and easy to understand, at first glance you may find it a bit like C or Perl. A paragraph of VCL is included here: Where sub is the keyword for declaring a subroutine, the available subroutines always start with vcl_, but if you create the subroutine yourself then you will not have the privilege of naming vcl_.
VCL syntax As I mentioned earlier, the VCL is structured in the same way as C or Perl, so the fact that a VCL code looks like C is obvious, even in syntax. String (string type value) When setting the string type value in VCL, make sure that it is always enclosed in quotation marks "..." and not in line. Even if you use regex, the declaration of special characters must also be in double quotes.
Operator Although it is a simple language, VCL also supports some operators such as: The subroutines are available The subroutines I declare here are the subroutines in Varnish 3. On Varnish 4, some subroutines have been renamed, see here. Again, the subroutine is a subroutine that clusters within the code so that it executes based on the meaning of each subroutine. Varnish provides a number of subroutines available:
vcl_recv The code in this group will be called when the client starts sending a query to the server, or after completing a query that has been received and analyzed. The purpose of this subroutine is to navigate the query sender's data so that Varnish can direct the query straight to the backend server without returning the cache to the client. The processing of this subroutine will be terminated by return (), which may contain keywords such as:  hash - When you return with this keyword, the user's page will be interpreted by Varnish as being able to cache the cache by assigning it a separate hash code, at which point Varnish will move to the vcl_hash subroutine for it to work.  pass - When you return with this keyword, Varnish will send the query directly to the backend server, you can understand if the pass will direct access to the backend server without the cache.  pipe - Forward the request to the Pipe Mode based on the vcl_pipe subroutine. Pur purge - Move the request object into a variant to remove, which will be handled via the vcl_hash subroutine and vcl_purge.
vcl_pipe As soon as the subroutine transfers the process to Pipe Mode via return (pipe), the code in the subroutine will be executed. Understand that, Pipe Mode is Varnish will open a bidirectional TCP Proxy connection that can be sent directly to the backend server and vice versa. Remember, if you use this subroutine, no other subroutines will be processed after the Pipe Mode finishes. Pipe Mode will end with return () with some keywords like:  pipe - passes the request to Pipe mode.
vcl_pass This subroutine will be applied when the request is sent to pass mode. Pass mode means that requests will be sent straight to the backend server and backend server will return data without access to any cache objects.
This subroutine will be terminated by return () with some keywords such as:  fetch - This request flag goes to pass mode and the backend server starts processing.  restart - restart the request transfer process.

vcl_hit The subroutine vcl_hit will be called when the request has found a successful cache in Varnish. vcl_hit will end the process with return () with the keyword:  deliver - Transfer the cache object to the request sender.  fetch - Resynchronizes object data that has been cached with content returned from the backend server. At this point, the vcl_miss subroutine will start working. Pass - Send request to pass mode with vcl_pass.  restart - restart the request transfer process.

vcl_miss

This subroutine will be triggered if the request does not find the appropriate cache object, or the request is fetched at the vcl_hit subroutine. It will also be terminated by return () with the following keywords:  fetch - retrieves the requested object to the backend. It will be controlled via the vcl_backend_fetch subroutine.

Pass - Put request into pass mode and process with vcl_pass.  restart - restart the request transfer process.

vcl_hash As soon as the requests are processed with vcl_recv which is returned (hash), the subroutine will work. It is used to find an object that has been cached in Varnish by a separate hash code. For this subroutine, there is only one way to end the process is return (lookup) to find a cache object.

vcl_purge Called out when the purge cache process started. It will end the process with return () with the keyword:  restart - restart the request transfer process.

vcl_deliver This subroutine will be invoked before any object is sent to the request sender, except for the result of the subroutine vcl_synth. It ends with return () with the

keyword:

 deliver - Transfer the cache object to the request sender.  restart - restart the request transfer process.

vcl_error

This subroutine will be executed when the backend server fails to access the data. The most common use is to declare the synthetic () function in this subroutine to create an error page in the Varnish. This subroutine myself will have some examples in the following.

Include statement in VCL

In addition to the default.vcl file by default, you can create other .vcl files and then you can use the include keyword in the default.vcl file to load it. Global variables

If you have read through the VCL content that you have been asked to copy you will see some variables such as req.url, req.request, ... What is it, Varnish what the variable? In this section you will understand. The list of global variables of VCL is very much so I just list some variables or use only, you can see more here. In addition, these global variables can be assigned values ​​by the set or unset keyword to unassign.

now

Displays the current time

. The following variables will retrieve information from the backend server:

.host

Hostname or IP address of Varnish Server.

.port

Get the port number used by Varnish.

The following variables will be used in the processing of requests:

client.ip

The client's IP address is sending the query.

client.identity

Identification code of the visitor.

server.hostname

The hostname of the server.

server.ip

The IP address of the server the visitor is visiting.

server.port

Port of the server that the visitor is visiting.

req.request

Request type: POST, GET, TRACE, HEAD, ....

req.url

URL sent request.

req.proto

HTTP protocol sent request.

req.backend

The name of the backend server is processing the request.

req.backend.healthy

Whether the backend is healthy or not. Requires an active probe to be set on the backend.

req.http.header

The header information of the requesting address.

req.hash_always_miss

If this variable is set to true, Varnish will not care about any objects returned from the backend server.

req.restarts

Displays the number of requests that have been restarted.

Some examples of VCL

Above you have read some important concepts in VCL, now I will give you some examples of VCL so you understand more about how it works.

Make a request to the backend server in http: // domain / wp-admin or wp-admin: Show the error page if the backend server is down.

Block links in other websites. For example, block images from your link on another website.

Some other VCL configuration sources include:  Varnish 3.0 VCL Template for WordPress, Joomla, Drupal.  Varnish 3.0 VCL Template Simple for WordPress.  Varnish VCL Template for Drupal

Epilogue

In this article I may have written a bit long and can finish Varnish 3 series here. Remember that your article is only general but can not be detailed Varnish VCL so go to Google type "Varnish Documentation" for more details to understand it more comprehensive.