diff --git a/projects/dns-yml/index.html b/projects/dns-yml/index.html index 2b3ff52..85d796e 100644 --- a/projects/dns-yml/index.html +++ b/projects/dns-yml/index.html @@ -1,9 +1,160 @@
DNS YAML

+ DNS YAML is infrastructure of code for the management of authoritative DNS + records. It allows its users to create yaml files describing the desired state + of their authoritative DNS records, which can then be applied to their DNS + server. DNS YAML does this through a concept called "mappers", which are + adapters that are able to interact with different types of authoritative DNS + solutions. The currently supported mappers are: +

+ + + + + +
powerdnsMaps to a powerdns mysql database.
scalewayMaps to the scaleway DNS service.
dryReads in the document and checks if it's valid + without actually mapping to anything.
+

+ The software can be obtained from the + source code repository or + as a docker image from docker hub.

+ +
+
Who Would This Be Useful For?
+
+
The Lone Selfhoster
+

+ If you're just managing your personal infrastructure and want to have a way to + manage the state of your DNS within the same version control repository as your + ansible scripts, DNS YAML will be the missing piece of the puzzle for you. +

+
+
+
The Cloud-Native Company
+

+ While it hasn't been tested in large deployments, I think that this DNS YAML + could theoretically be a great addition for large bodies of people who work + on applications within the same infrastructure. Traditionally, DNS records + are something that is managed by sysadmins who edit zone files by hand, or + through self-service UIs that some employees are allowed to acces. If one + were to, in stead, use version controlled DNS YAML documents in combination + with CI/CD, the following things would be achieved: +

+ +
    +
  1. + Employees can create pull requests with DNS record changes that their + projects require. These could be reviewed and merged by employees who are + responsible for infrastructure, after which they can be applied to + staging/production environments through the CI/CD system. +
  2. +
  3. + The state of the DNS is reproducible. If the DNS service were to fail and + its state was lost, it would be trivial to replace it and reapply its state + with the DNS YAML document. +
  4. +
  5. + Changes to DNS records are autidable through version control. +
  6. +
  7. + Lastly, but not unimportantly, automated CI jobs could be setup for DNS YAML + repositories to scan for stale DNS records that point to infrastructure that + is no longer under the companies control. This is important, because leaving + stale records unattended can be a security risk. Take A records that point + to IP addresses that are not controlled by the company anymore for + example. Those could be abused by bad actors who want to impersonate the + company if they were to get their hands on that old IP address. +
  8. +
+
+
+ +
+
An Example
+

+ To help you get an idea, here is an example of a DNS YAML document, with below + it a Done CI file that could be used to check the document for validity and + apply it to production. The document contains examples of the different types + of record values that DNS YAML allows to be configured, which + are raw, file or round-robin. +

+
+
domains:
+
  example.com:
+
    records:
+
      - type: A
+
        name: example.com
+
        content:
+
          type: raw
+
          value: 127.0.0.1
+
      - type: A
+
        name: example.com
+
        content:
+
          type: round-robin
+
          value: http-cluster
+
  mail.example.com:
+
    records:
+
      - type: MX
+
        name: mx.mail.example.com
+
        content:
+
          type: round-robin
+
          value: mail-exchange
+
      - type: TXT
+
        name: _dkim.mx.mail.example.com
+
        content:
+
          type: file
+
          value: dkim/mail.example.com.txt
+

+  
round_robins:
+
  http-cluster:
+
    - 127.0.0.1
+
    - 127.0.0.2
+
    - 127.0.0.3
+
  mail-exchange:
+
    - mxa.examplemail.com
+
    - mxb.examplemail.com
+
+
+ +
+

+ Below is a Drone CI pipeline configuration that validates the documents by + using the dry mapper and then applies the document to production + through the scaleway DNS service API using the scaleway mapper. +

+
+
kind: pipeline
+
type: docker
+
name: default
+
steps:
+
  - name: validate
+
    image: hugotty/dns-yml:latest
+
    commands:
+
      - /dns-yml -mapper dry ./dns.yml
+

+  
  - name: publish
+
    image: hugotty/dns-yml:latest
+
    environment:
+
      DNS_YML_SCW_ORG_ID:
+
        from_secret: scaleway_org_id
+
      DNS_YML_SCW_ACCESS_KEY:
+
        from_secret: scaleway_access_key
+
      DNS_YML_SCW_SECRET_KEY:
+
        from_secret: scaleway_secret
+
    commands:
+
      - /dns-yml ./dns.yml
+
    when:
+
      branch:
+
        - master
+
    event:
+
      - push
+
+
+ diff --git a/projects/dns-yml/last_checksum.txt b/projects/dns-yml/last_checksum.txt index c5d9794..696fa95 100644 --- a/projects/dns-yml/last_checksum.txt +++ b/projects/dns-yml/last_checksum.txt @@ -1 +1 @@ -675167167 108 +72850756 6424 diff --git a/projects/dns-yml/last_edit_date.txt b/projects/dns-yml/last_edit_date.txt new file mode 100644 index 0000000..d4dbb10 --- /dev/null +++ b/projects/dns-yml/last_edit_date.txt @@ -0,0 +1 @@ +1653457975 diff --git a/projects/phpinspect.el/index.html b/projects/phpinspect.el/index.html index 1933643..32fdc44 100644 --- a/projects/phpinspect.el/index.html +++ b/projects/phpinspect.el/index.html @@ -18,7 +18,7 @@ of them had problems for my use cases. I encountered performance issues (language servers implemented in PHP would have massive memory consumption), lack of sophistication (ctags based solutions don't understand object oriented - code well enough) or simply a lack of features. After a while I got obsessed + code well enough) or simply a lack of features. After a while I got invested enough to start implementing a solution myself with the main goals of being able to work with large projects, being sophisticated enough to understand object oriented code and being simple to setup from within emacs. diff --git a/projects/phpinspect.el/last_checksum.txt b/projects/phpinspect.el/last_checksum.txt index c7f6019..5be0796 100644 --- a/projects/phpinspect.el/last_checksum.txt +++ b/projects/phpinspect.el/last_checksum.txt @@ -1 +1 @@ -4156153914 2489 +2123635943 2489 diff --git a/projects/phpinspect.el/last_edit_date.txt b/projects/phpinspect.el/last_edit_date.txt index 06e7fad..7e03178 100644 --- a/projects/phpinspect.el/last_edit_date.txt +++ b/projects/phpinspect.el/last_edit_date.txt @@ -1 +1 @@ -1653408807 +1653458071 diff --git a/style.css b/style.css index 2e376ec..308215a 100644 --- a/style.css +++ b/style.css @@ -3,6 +3,7 @@ :root { --theme-bright: #f9f5eb; --theme-text: #5b4636; + --theme-default: #f4ecd8; } a:visited { @@ -36,10 +37,12 @@ p { margin-block-start: 0; } -p + p { +p + p, section + section, table + table, table + p, p + table { margin-block-start: 1em; } + + aside { width: inherit; } @@ -199,3 +202,54 @@ article > section > section > section > header { margin-block-start: 1.33em; margin-block-end: 1.33em; } + +.code-sample { + font-family: Hack, monospace; + background-color: var(--theme-bright); + border-radius: 0.2em; + counter-reset: line; + padding: 0.5em; + border-left: 0.2em solid var(--theme-text); + border-bottom: 0.2em solid var(--theme-text); +} + +.code-sample pre { + margin: 0; + padding: 0; +} + +.code-sample > pre:before { + counter-increment: line; + content: counter(line); + display: inline-block; + padding-right: 0.3em; + min-width: 3ch; +} + +table { + border: 1px solid var(--theme-text); + min-width: 100%; + margin: 0; + background-color: var(--theme-bright); + border-radius: 0.5rem; + border-spacing: 0; +} + +table td { + padding: 0.2em; +} + +table td + td, table th + th { + margin: 0; + border-left: 1px solid var(--theme-text); +} + +table th, table td { + padding: 0.3em; + text-align: left; + vertical-align: top; +} + +table tr:not(:first-child) td { + border-top: 1px solid var(--theme-text); +}