mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-02-03 23:40:14 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu Wang
commit
6038ed5a7f
@ -1,5 +1,5 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: translator: (chenmu-kk)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
|
||||
@ -0,0 +1,66 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Project OWL: IoT trying to hold connectivity together in disasters)
|
||||
[#]: via: (https://www.networkworld.com/article/3564980/project-owl-iot-trying-to-hold-connectivity-together-in-disasters.html)
|
||||
[#]: author: (Jon Gold https://www.networkworld.com/author/Jon-Gold/)
|
||||
|
||||
Project OWL: IoT trying to hold connectivity together in disasters
|
||||
======
|
||||
IoT devices configured in a wireless mesh network can be quickly deployed to provide basic connections when natural disasters knock out traditional communications links.
|
||||
[AK Badwolf][1] [(CC BY 2.0)][2]
|
||||
|
||||
An open source project centered on mesh networking, [IoT][3] and LoRa connectivity could help emergency responders and victims stay in contact in the wake of natural disasters, said the head of Project OWL at the recent Open Source Summit.
|
||||
|
||||
Project OWL’s target is the disruption in communications that often follows natural disaster. Widespread outages, in both cellular and wired networks, frequently impede the flow of information about emergency services, supplies and a host of other critical concerns that have to be addressed in the wake of a major storm or other catastrophe.
|
||||
|
||||
**Learn about 5G and WiFi 6**
|
||||
|
||||
* [How to determine if WiFi 6 is right for you][4]
|
||||
* [What is MU-MIMO? Why do you need it in your wireless routers?][5]
|
||||
* [When to use 5G, when to use WiFi 6][6]
|
||||
* [How enterprises can prep for 5G networks][7]
|
||||
|
||||
|
||||
|
||||
It does this with an army of “ducks” – small wireless modules that are cheap, simple-to-deploy and don’t require the support of existing infrastructure. Some ducks are solar-powered, others have long-lasting batteries. A duck is equipped with a LoRa radio for communication with other ducks on the network, as well as with Wi-Fi and perhaps Bluetooth or GPS for additional functionality.
|
||||
|
||||
The idea is that, when networks are down, users can use their smartphones or laptops to make a [Wi-Fi][8] connection to a duck, which can relay small pieces of information to the rest of the network. Information propagates back along the network until it reaches a “Papaduck,” which is equipped with a satellite connection to the OWL data management system in the cloud. (OWL stands for “organization, whereabouts, and logistics.”) From the cloud, the information can be visualized on a smartphone or web app, or even plugged into existing systems via an API.
|
||||
|
||||
The secret sauce is in the ClusterDuck Protocol, the open source firmware that keeps information flowing even when some modules on the network aren’t functional. It’s designed to work on a wide range of cheap and easily accessed computing hardware – Raspberry Pis and the like – in order to make it easy to set up a ClusterDuck network quickly.
|
||||
|
||||
The project was prompted, according to founder Bryan Knouse, by the devastating hurricanes of 2017 and 2018, and the huge difficulties faced by affected communities in responding to them without adequate communications.
|
||||
|
||||
“A few of our founding members had been through these disasters, and we asked ‘what do we do about this?’” he said.
|
||||
|
||||
The project has a cohort of students and professors at the University of Puerto Rico in Mayaguez, and most of the testing of the system happened there. Knouse said there are currently 17 solar-powered ducks nesting on rooftops and trees around campus, with plans to add more.
|
||||
|
||||
“This relationship created an open-source community on the ground, these students and profs are helping us develop this,” he said.
|
||||
|
||||
Join the Network World communities on [Facebook][9] and [LinkedIn][10] to comment on topics that are top of mind.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.networkworld.com/article/3564980/project-owl-iot-trying-to-hold-connectivity-together-in-disasters.html
|
||||
|
||||
作者：[Jon Gold][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://www.networkworld.com/author/Jon-Gold/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://www.flickr.com/photos/spiderkat/8487309555/in/photolist-dVZFrn-dDctnA-8WuLez-6RBSHn-bQa5F8-syyFcV-rvxKJT-5bSAh-2Xey4-3D4xww-4t1ZYv-dMgY7k-mHeMk1-xsPw6B-EiD3UR-k1rNkD-atorAv-f58MG9-g2QCe-Zr1wAC-ewx5Px-6vrwz7-8CCPSd-hAC5HZ-aHJC1B-9ovTST-Wqj4Sk-fiJjWG-28ATb9y-6tHHiR-8VZrmy-8iUVNB-DzSQV5-j6gpDL-2c2C5Re-kmbqae-Th4XGx-g325LW-cC1cp-26aa3aC-X7ruJo-jDkSKD-57695d-8Dz2hm-fPsDJr-gxcdoV-iSVsHR-dWWbct-ejvCrM-8ofaVz
|
||||
[2]: https://creativecommons.org/licenses/by/2.0/legalcode
|
||||
[3]: https://www.networkworld.com/article/3207535/what-is-iot-the-internet-of-things-explained.html
|
||||
[4]: https://www.networkworld.com/article/3356838/how-to-determine-if-wi-fi-6-is-right-for-you.html
|
||||
[5]: https://www.networkworld.com/article/3250268/what-is-mu-mimo-and-why-you-need-it-in-your-wireless-routers.html
|
||||
[6]: https://www.networkworld.com/article/3402316/when-to-use-5g-when-to-use-wi-fi-6.html
|
||||
[7]: https://www.networkworld.com/article/3306720/mobile-wireless/how-enterprises-can-prep-for-5g.html
|
||||
[8]: https://www.networkworld.com/article/3560993/what-is-wi-fi-and-why-is-it-so-important.html
|
||||
[9]: https://www.facebook.com/NetworkWorld/
|
||||
[10]: https://www.linkedin.com/company/network-world
|
||||
@ -1,5 +1,5 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: translator: (summer2233)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
|
||||
@ -0,0 +1,735 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (A guide to Terraform for Kubernetes beginners)
|
||||
[#]: via: (https://opensource.com/article/20/7/terraform-kubernetes)
|
||||
[#]: author: (Jessica Cherry https://opensource.com/users/cherrybomb)
|
||||
|
||||
A guide to Terraform for Kubernetes beginners
|
||||
======
|
||||
Learn how to make a Minikube cluster and deploy to it with Terraform.
|
||||
![A person programming][1]
|
||||
|
||||
When I build infrastructure, I do it as code. The movement toward [infrastructure as code][2] means that every change is visible, whether it's through configuration management files or full-blown [GitOps][3].
|
||||
|
||||
[Terraform][4] is a tool for building, upgrading, and maintaining your infrastructure as code. As its [GitHub page][5] explains:
|
||||
|
||||
> "Terraform enables you to safely and predictably create, change, and improve infrastructure. It is an open source tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned."
|
||||
|
||||
The best part is you can import your existing infrastructure into a Terraform configuration state, and all future changes will be tracked. That tracking provides a complete understanding of your production environment (and any other environments), which can be backed up to a local or remote Git repository to version-control the entire infrastructure.
|
||||
|
||||
In this article, I will explain how to use Terraform to manage state in a Minikube Kubernetes cluster.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
Terraform is cloud-agnostic, so you can run about any type of Kubernetes cluster in any cloud by using the associated providers. A [provider][6] is the core of Terraform's plugin architecture, and each provider is "responsible for understanding API interactions and exposing resources" so that the main Terraform project can remain lean, but the project can expand to any system.
|
||||
|
||||
In this example, I'll use [Terraform 11][7] on a Linux desktop. To follow along, you will also need [Helm 2.16.7][8], [Minikube][9], and [kubectl][10]:
|
||||
|
||||
* Download and configure Minikube by following this [documentation][11].
|
||||
* Download and configure Helm [using your package manager][12] or do it manually from the [releases][13].
|
||||
* Download and install kubectl by following [these steps][10].
|
||||
* Install Terraform by downloading the [Linux .tar file][14], untar the file, and move it to `/usr/local/bin/terraform`.
|
||||
|
||||
|
||||
|
||||
Before running a build, find out what the command-line utility offers. Run `terraform`, and the output will show the execution plan and apply commands. At the bottom, there is an upgrade checklist that will come in handy if you are on an older version of Terraform. The developers have built in a great command to check compatibility between versions.
|
||||
|
||||
### Getting started
|
||||
|
||||
To build something in Terraform, you need to create [modules][15], which are folders with a set of configuration files that can gather information and execute the action you need to complete. Terraform files always end in the file extension `.tf`. Start with one `main.tf` file, such as:
|
||||
|
||||
|
||||
```
|
||||
`jess@Athena:~/terraform_doc$ touch main.tf`
|
||||
```
|
||||
|
||||
You also need to know some basic Terraform commands and requirements before you can start making anything within the cluster:
|
||||
|
||||
* `terraform init`: Initializes a Terraform working directory
|
||||
– It must be within the same directory as the `.tf` files or nothing will happen.
|
||||
* `terraform validate`: Confirms the Terraform file's syntax is correct
|
||||
– Always run this to confirm the code is built correctly and will not have errors.
|
||||
* `terraform plan`: Generates and shows what will change when you run `terraform apply`
|
||||
– Run this before `apply` to confirm the results are as you intend.
|
||||
* `terraform apply`: Builds or changes infrastructure
|
||||
– It will show the execution plan and requires a yes or no to execute unless you use the `--auto-approve` flag, which will make it execute automatically.
|
||||
* `Terraform refresh`: Updates the local state file against real resources
|
||||
– This ensures Terraform has an accurate view of what is in the current environment.
|
||||
* `terraform destroy`: Deletes and removes Terraform-managed infrastructure
|
||||
– This will permanently remove anything created and stored in the state file from the cluster.
|
||||
|
||||
|
||||
|
||||
For the configuration in this example, everything controlled by Terraform is held in a local state file. According to Terraform's [docs][16]:
|
||||
|
||||
> "This state is stored by default in a local file named `terraform.tfstate`, but it can also be stored remotely, which works better in a team environment. Terraform uses this local state to create plans and make changes to your infrastructure. Prior to any operation, Terraform does a refresh to update the state with the real infrastructure."
|
||||
|
||||
Now that you have this background information, you can move on and edit your `main.tf` file, check your cluster, and work towards adding configurations with Terraform.
|
||||
|
||||
### Prep and build Minikube
|
||||
|
||||
Before getting started with Terraform, you must create a Minikube cluster. This example uses Minikube version v1.9.2. Run `minikube start`:
|
||||
|
||||
|
||||
```
|
||||
jess@Athena:~/terraform_doc$ minikube start
|
||||
🎉 minikube 1.11.0 is available! Download it: <https://github.com/kubernetes/minikube/releases/tag/v1.11.0>
|
||||
💡 To disable this notice, run: 'minikube config set WantUpdateNotification false'
|
||||
|
||||
🙄 minikube v1.9.2 on Ubuntu 18.04
|
||||
✨ Using the kvm2 driver based on existing profile
|
||||
👍 Starting control plane node m01 in cluster minikube
|
||||
🔄 Restarting existing kvm2 VM for "minikube" ...
|
||||
🐳 Preparing Kubernetes v1.18.0 on Docker 19.03.8 ...
|
||||
🌟 Enabling addons: default-storageclass, storage-provisioner
|
||||
🏄 Done! kubectl is now configured to use "minikube"
|
||||
```
|
||||
|
||||
### Check your new cluster and add a namespace
|
||||
|
||||
Check your new Minikube cluster with your trusty `kubectl` commands:
|
||||
|
||||
|
||||
```
|
||||
jess@Athena:~/terraform_doc$ kubectl get nodes
|
||||
NAME STATUS ROLES AGE VERSION
|
||||
minikube Ready master 4m5s v1.18.0
|
||||
```
|
||||
|
||||
The cluster is up and running, so add configurations to your `main.tf` file. First, you'll need a [provider][6], which "is responsible for understanding API interactions and exposing resources." The provider in this example will be (aptly) named [Kubernetes][17]. Edit your `main.tf` file and add the provider:
|
||||
|
||||
|
||||
```
|
||||
provider "kubernetes" {
|
||||
config_context_cluster = "minikube"
|
||||
}
|
||||
```
|
||||
|
||||
This syntax tells Terraform that the cluster is running in Minikube.
|
||||
|
||||
Now you will need a definition of a resource block. A resource block describes one or more infrastructure objects, such as virtual networks, compute instances, or higher-level components such as DNS records.
|
||||
|
||||
Add one Kubernetes namespace to the cluster:
|
||||
|
||||
|
||||
```
|
||||
resource "kubernetes_namespace" "1-minikube-namespace" {
|
||||
metadata {
|
||||
name = "my-first-terraform-namespace"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Next, run the `terraform init` command to check your provider version and initialize Terraform:
|
||||
|
||||
|
||||
```
|
||||
jess@Athena:~/terraform_doc$ terraform init
|
||||
|
||||
Initializing provider plugins...
|
||||
|
||||
The following providers do not have any version constraints in configuration,
|
||||
so the latest version was installed.
|
||||
|
||||
To prevent automatic upgrades to new major versions that may contain breaking
|
||||
changes, it is recommended to add version = "..." constraints to the
|
||||
corresponding provider blocks in configuration, with the constraint strings
|
||||
suggested below.
|
||||
|
||||
* provider.kubernetes: version = "~> 1.11"
|
||||
|
||||
Terraform has been successfully initialized!
|
||||
|
||||
You may now begin working with Terraform. Try running "terraform plan" to see
|
||||
any changes that are required for your infrastructure. All Terraform commands
|
||||
should now work.
|
||||
|
||||
If you ever set or change modules or backend configuration for Terraform,
|
||||
rerun this command to reinitialize your working directory. If you forget, other
|
||||
commands will detect it and remind you to do so if necessary.
|
||||
```
|
||||
|
||||
Run your plan to see what will be executed:
|
||||
|
||||
|
||||
```
|
||||
jess@Athena:~/terraform_doc$ terraform plan
|
||||
Refreshing Terraform state in-memory prior to plan...
|
||||
The refreshed state will be used to calculate this plan, but will not be
|
||||
persisted to local or remote state storage.
|
||||
|
||||
\------------------------------------------------------------------------
|
||||
|
||||
An execution plan has been generated and is shown below.
|
||||
Resource actions are indicated with the following symbols:
|
||||
+ create
|
||||
|
||||
Terraform will perform the following actions:
|
||||
|
||||
+ kubernetes_namespace.1-minikube-namespace
|
||||
id: <computed>
|
||||
metadata.#: "1"
|
||||
metadata.0.generation: <computed>
|
||||
metadata.0.name: "my-first-terraform-namespace"
|
||||
metadata.0.resource_version: <computed>
|
||||
metadata.0.self_link: <computed>
|
||||
metadata.0.uid: <computed>
|
||||
|
||||
Plan: 1 to add, 0 to change, 0 to destroy.
|
||||
|
||||
\------------------------------------------------------------------------
|
||||
|
||||
Note: You didn't specify an "-out" parameter to save this plan, so Terraform
|
||||
can't guarantee that exactly these actions will be performed if
|
||||
"terraform apply" is subsequently run.
|
||||
```
|
||||
|
||||
Now that you know what Terraform will do, apply your configuration:
|
||||
|
||||
|
||||
```
|
||||
jess@Athena:~/terraform_doc$ terraform apply
|
||||
|
||||
An execution plan has been generated and is shown below.
|
||||
Resource actions are indicated with the following symbols:
|
||||
+ create
|
||||
|
||||
Terraform will perform the following actions:
|
||||
|
||||
+ kubernetes_namespace.1-minikube-namespace
|
||||
id: <computed>
|
||||
metadata.#: "1"
|
||||
metadata.0.generation: <computed>
|
||||
metadata.0.name: "my-first-terraform-namespace"
|
||||
metadata.0.resource_version: <computed>
|
||||
metadata.0.self_link: <computed>
|
||||
metadata.0.uid: <computed>
|
||||
|
||||
Plan: 1 to add, 0 to change, 0 to destroy.
|
||||
|
||||
Do you want to perform these actions?
|
||||
Terraform will perform the actions described above.
|
||||
Only 'yes' will be accepted to approve.
|
||||
|
||||
Enter a value: yes
|
||||
|
||||
\-----------------------------------
|
||||
|
||||
kubernetes_namespace.1-minikube-namespace: Creating...
|
||||
metadata.#: "" => "1"
|
||||
metadata.0.generation: "" => "<computed>"
|
||||
metadata.0.name: "" => "my-first-terraform-namespace"
|
||||
metadata.0.resource_version: "" => "<computed>"
|
||||
metadata.0.self_link: "" => "<computed>"
|
||||
metadata.0.uid: "" => "<computed>"
|
||||
kubernetes_namespace.1-minikube-namespace: Creation complete after 0s (ID: my-first-terraform-namespace)
|
||||
|
||||
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
|
||||
```
|
||||
|
||||
Finally, confirm that your new namespace exists by running `kubectl get ns`:
|
||||
|
||||
|
||||
```
|
||||
jess@Athena:~/terraform_doc$ kubectl get ns
|
||||
NAME STATUS AGE
|
||||
default Active 28d
|
||||
kube-node-lease Active 28d
|
||||
kube-public Active 28d
|
||||
kube-system Active 28d
|
||||
my-first-terraform-namespace Active 2m19s
|
||||
```
|
||||
|
||||
### Run it through a Helm chart
|
||||
|
||||
The ability to manually write a Terraform configuration file, run it, and see results in Kubernetes is nice. What's even nicer? Being able to rerun the same commands through a Helm chart.
|
||||
|
||||
Run the `helm create <name>` command to generate a chart:
|
||||
|
||||
|
||||
```
|
||||
$ helm create buildachart
|
||||
Creating buildachart
|
||||
```
|
||||
|
||||
You need another provider block for this exercise. There is a specific Helm provider, and it requires a Kubernetes cluster name so that Helm knows where to install its chart. Add the new provider, which is shown below, to your existing `main.tf` file:
|
||||
|
||||
|
||||
```
|
||||
provider "helm" {
|
||||
kubernetes {
|
||||
config_context_cluster = "minikube"
|
||||
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Now that Helm is configured, you need to add a Helm chart for this terraform module to install. To keep things simple, keep the Helm chart in the same folder you're using for your Terraform state:
|
||||
|
||||
|
||||
```
|
||||
jess@Athena:~/terraform_doc$ ls
|
||||
buildachart main.tf terraform.tfstate
|
||||
```
|
||||
|
||||
Add the new Helm resource so that the chart can be installed and tracked through your Terraform state by using the `helm_release` resource. I named this resource `local` and imported my chart name and my chart location:
|
||||
|
||||
|
||||
```
|
||||
resource "helm_release" "local" {
|
||||
name = "buildachart"
|
||||
chart = "./buildachart"
|
||||
}
|
||||
```
|
||||
|
||||
Now that you've added these pieces, run Terraform's initialization command again. It will update the state based on your changes, including downloading a new provider:
|
||||
|
||||
|
||||
```
|
||||
jess@Athena:~/terraform_doc$ terraform init
|
||||
|
||||
Initializing provider plugins...
|
||||
\- Checking for available provider plugins on <https://releases.hashicorp.com>...
|
||||
\- Downloading plugin for provider "helm" (1.2.2)...
|
||||
|
||||
The following providers do not have any version constraints in configuration,
|
||||
so the latest version was installed.
|
||||
|
||||
To prevent automatic upgrades to new major versions that may contain breaking
|
||||
changes, it is recommended to add version = "..." constraints to the
|
||||
corresponding provider blocks in configuration, with the constraint strings
|
||||
suggested below.
|
||||
|
||||
* provider.helm: version = "~> 1.2"
|
||||
* provider.kubernetes: version = "~> 1.11"
|
||||
|
||||
Terraform has been successfully initialized!
|
||||
|
||||
You may now begin working with Terraform. Try running "terraform plan" to see
|
||||
any changes that are required for your infrastructure. All Terraform commands
|
||||
should now work.
|
||||
|
||||
If you ever set or change modules or backend configuration for Terraform,
|
||||
rerun this command to reinitialize your working directory. If you forget, other
|
||||
commands will detect it and remind you to do so if necessary.
|
||||
```
|
||||
|
||||
Then plan your new configurations:
|
||||
|
||||
|
||||
```
|
||||
jess@Athena:~/terraform_doc$ terraform plan
|
||||
Refreshing Terraform state in-memory prior to plan...
|
||||
The refreshed state will be used to calculate this plan, but will not be
|
||||
persisted to local or remote state storage.
|
||||
|
||||
kubernetes_namespace.1-minikube-namespace: Refreshing state... (ID: my-first-terraform-namespace)
|
||||
|
||||
\------------------------------------------------------------------------
|
||||
|
||||
An execution plan has been generated and is shown below.
|
||||
Resource actions are indicated with the following symbols:
|
||||
+ create
|
||||
|
||||
Terraform will perform the following actions:
|
||||
|
||||
+ helm_release.local
|
||||
id: <computed>
|
||||
atomic: "false"
|
||||
chart: "./buildachart"
|
||||
cleanup_on_fail: "false"
|
||||
create_namespace: "false"
|
||||
dependency_update: "false"
|
||||
disable_crd_hooks: "false"
|
||||
disable_openapi_validation: "false"
|
||||
disable_webhooks: "false"
|
||||
force_update: "false"
|
||||
lint: "false"
|
||||
max_history: "0"
|
||||
metadata.#: <computed>
|
||||
name: "buildachart"
|
||||
namespace: "default"
|
||||
recreate_pods: "false"
|
||||
render_subchart_notes: "true"
|
||||
replace: "false"
|
||||
reset_values: "false"
|
||||
reuse_values: "false"
|
||||
skip_crds: "false"
|
||||
status: "deployed"
|
||||
timeout: "300"
|
||||
verify: "false"
|
||||
version: "0.1.0"
|
||||
wait: "true"
|
||||
|
||||
Plan: 1 to add, 0 to change, 0 to destroy.
|
||||
|
||||
\------------------------------------------------------------------------
|
||||
|
||||
Note: You didn't specify an "-out" parameter to save this plan, so Terraform
|
||||
can't guarantee that exactly these actions will be performed if
|
||||
"terraform apply" is subsequently run.
|
||||
```
|
||||
|
||||
Apply your configuration, only this time add the `--auto-approve` flag so it will execute without confirmation:
|
||||
|
||||
|
||||
```
|
||||
jess@Athena:~/terraform_doc$ terraform apply --auto-approve
|
||||
kubernetes_namespace.1-minikube-namespace: Refreshing state... (ID: my-first-terraform-namespace)
|
||||
helm_release.local: Creating...
|
||||
atomic: "" => "false"
|
||||
chart: "" => "./buildachart"
|
||||
cleanup_on_fail: "" => "false"
|
||||
create_namespace: "" => "false"
|
||||
dependency_update: "" => "false"
|
||||
disable_crd_hooks: "" => "false"
|
||||
disable_openapi_validation: "" => "false"
|
||||
disable_webhooks: "" => "false"
|
||||
force_update: "" => "false"
|
||||
lint: "" => "false"
|
||||
max_history: "" => "0"
|
||||
metadata.#: "" => "<computed>"
|
||||
name: "" => "buildachart"
|
||||
namespace: "" => "default"
|
||||
recreate_pods: "" => "false"
|
||||
render_subchart_notes: "" => "true"
|
||||
replace: "" => "false"
|
||||
reset_values: "" => "false"
|
||||
reuse_values: "" => "false"
|
||||
skip_crds: "" => "false"
|
||||
status: "" => "deployed"
|
||||
timeout: "" => "300"
|
||||
verify: "" => "false"
|
||||
version: "" => "0.1.0"
|
||||
wait: "" => "true"
|
||||
helm_release.local: Creation complete after 8s (ID: buildachart)
|
||||
|
||||
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
|
||||
```
|
||||
|
||||
Although it says the chart deployed, it's always nice to double-check and confirm that the new Helm chart is in place. Check to see if your pod made it by using a `kubectl` command:
|
||||
|
||||
|
||||
```
|
||||
jess@Athena:~/terraform_doc$ kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
buildachart-68c86ccf5f-lchc5 1/1 Running 0 43s
|
||||
```
|
||||
|
||||
This confirms your pod is running, which means your chart deployed! You also have a new backup state file:
|
||||
|
||||
|
||||
```
|
||||
jess@Athena:~/terraform_doc$ ls
|
||||
buildachart main.tf terraform.tfstate terraform.tfstate.backup
|
||||
```
|
||||
|
||||
Terraform is protective of state, which is a great feature. It automatically generates a previous-state file after each update. This allows version control of your infrastructure, and you can always save the current and most recent state. Since this is a local build, stick with the current and previous states without version control.
|
||||
|
||||
### Rollback a change and import something
|
||||
|
||||
As you run Terraform commands, the backup state file is generated and updated, which means you can roll back previous changes exactly once unless you are holding state files in storage somewhere else (e.g., a database) with other configurations to manage the files.
|
||||
|
||||
In this example, you need to roll back your Helm chart deployment. Why? Well, because you can.
|
||||
|
||||
Before you do anything, take a minute to run the `terraform refresh` command to see if there is anything different between the cluster and the current state:
|
||||
|
||||
|
||||
```
|
||||
jess@Athena:~/terraform_doc$ terraform refresh
|
||||
helm_release.local: Refreshing state... (ID: buildachart)
|
||||
kubernetes_namespace.1-minikube-namespace: Refreshing state... (ID: my-first-terraform-namespace)
|
||||
```
|
||||
|
||||
There is a weird workaround to roll back changes: You can overwrite your state file with the backup file, or you can comment the code changes you rolled out through Terraform files and allow Terraform to destroy them.
|
||||
|
||||
In this example, I'll comment-out code and rerun Terraform, so the Helm chart will be deleted. Comments begin with `//` in Terraform files:
|
||||
|
||||
|
||||
```
|
||||
jess@Athena:~/terraform_doc$ cat main.tf
|
||||
provider "kubernetes" {
|
||||
config_context_cluster = "minikube"
|
||||
}
|
||||
|
||||
resource "kubernetes_namespace" "1-minikube-namespace" {
|
||||
metadata {
|
||||
name = "my-first-terraform-namespace"
|
||||
}
|
||||
}
|
||||
|
||||
//provider "helm" {
|
||||
// kubernetes {
|
||||
// config_context_cluster = "minikube"
|
||||
// }
|
||||
//}
|
||||
//resource "helm_release" "local" {
|
||||
// name = "buildachart"
|
||||
// chart = "./buildachart"
|
||||
//}
|
||||
```
|
||||
|
||||
After you comment everything out, run `terraform apply`:
|
||||
|
||||
|
||||
```
|
||||
jess@Athena:~/terraform_doc$ terraform apply
|
||||
helm_release.local: Refreshing state... (ID: buildachart)
|
||||
null_resource.minikube: Refreshing state... (ID: 4797320155365789412)
|
||||
kubernetes_namespace.1-minikube-namespace: Refreshing state... (ID: my-terraform-namespace)
|
||||
|
||||
An execution plan has been generated and is shown below.
|
||||
Resource actions are indicated with the following symbols:
|
||||
- destroy
|
||||
|
||||
Terraform will perform the following actions:
|
||||
|
||||
- helm_release.local
|
||||
|
||||
Plan: 0 to add, 0 to change, 1 to destroy.
|
||||
|
||||
Do you want to perform these actions?
|
||||
Terraform will perform the actions described above.
|
||||
Only 'yes' will be accepted to approve.
|
||||
|
||||
Enter a value: yes
|
||||
|
||||
helm_release.local: Destroying... (ID: buildachart)
|
||||
helm_release.local: Destruction complete after 0s
|
||||
|
||||
Apply complete! Resources: 0 added, 0 changed, 1 destroyed.
|
||||
```
|
||||
|
||||
To see what overwriting the file looks like, reapply the Helm chart and overwrite the state file. Here is a snippet of the chart being recreated (this text output can be pretty long):
|
||||
|
||||
|
||||
```
|
||||
helm_release.local: Still creating... (10s elapsed)
|
||||
helm_release.local: Creation complete after 15s (ID: buildachart)
|
||||
|
||||
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
|
||||
|
||||
Here’s the file overwrite and the plan showing that the helm chart needs to be rerun.
|
||||
jess@Athena:~/terraform_doc$ cp terraform.tfstate.backup terraform.tfstate
|
||||
jess@Athena:~/terraform_doc$ terraform plan
|
||||
Refreshing Terraform state in-memory prior to plan...
|
||||
The refreshed state will be used to calculate this plan, but will not be
|
||||
persisted to local or remote state storage.
|
||||
|
||||
null_resource.minikube: Refreshing state... (ID: 4797320155365789412)
|
||||
kubernetes_namespace.1-minikube-namespace: Refreshing state... (ID: my-terraform-namespace)
|
||||
|
||||
\------------------------------------------------------------------------
|
||||
|
||||
An execution plan has been generated and is shown below.
|
||||
Resource actions are indicated with the following symbols:
|
||||
+ create
|
||||
|
||||
Terraform will perform the following actions:
|
||||
|
||||
+ helm_release.local
|
||||
id: <computed>
|
||||
atomic: "false"
|
||||
chart: "./buildachart"
|
||||
cleanup_on_fail: "false"
|
||||
create_namespace: "false"
|
||||
dependency_update: "false"
|
||||
disable_crd_hooks: "false"
|
||||
disable_openapi_validation: "false"
|
||||
disable_webhooks: "false"
|
||||
force_update: "false"
|
||||
max_history: "0"
|
||||
metadata.#: <computed>
|
||||
name: "buildachart"
|
||||
namespace: "default"
|
||||
recreate_pods: "false"
|
||||
render_subchart_notes: "true"
|
||||
replace: "false"
|
||||
reset_values: "false"
|
||||
reuse_values: "false"
|
||||
skip_crds: "false"
|
||||
status: "deployed"
|
||||
timeout: "300"
|
||||
verify: "false"
|
||||
version: "0.1.0"
|
||||
wait: "true"
|
||||
|
||||
Plan: 1 to add, 0 to change, 0 to destroy.
|
||||
|
||||
\------------------------------------------------------------------------
|
||||
|
||||
Note: You didn't specify an "-out" parameter to save this plan, so Terraform
|
||||
can't guarantee that exactly these actions will be performed if
|
||||
"terraform apply" is subsequently run.
|
||||
```
|
||||
|
||||
Be aware that you will run into a problem if you do not clean up the environment when overwriting your state files. That problem shows up in the name usage:
|
||||
|
||||
|
||||
```
|
||||
Do you want to perform these actions?
|
||||
Terraform will perform the actions described above.
|
||||
Only 'yes' will be accepted to approve.
|
||||
|
||||
Enter a value: yes
|
||||
|
||||
helm_release.local: Creating...
|
||||
atomic: "" => "false"
|
||||
chart: "" => "./buildachart"
|
||||
cleanup_on_fail: "" => "false"
|
||||
create_namespace: "" => "false"
|
||||
dependency_update: "" => "false"
|
||||
disable_crd_hooks: "" => "false"
|
||||
disable_openapi_validation: "" => "false"
|
||||
disable_webhooks: "" => "false"
|
||||
force_update: "" => "false"
|
||||
max_history: "" => "0"
|
||||
metadata.#: "" => "<computed>"
|
||||
name: "" => "buildachart"
|
||||
namespace: "" => "default"
|
||||
recreate_pods: "" => "false"
|
||||
render_subchart_notes: "" => "true"
|
||||
replace: "" => "false"
|
||||
reset_values: "" => "false"
|
||||
reuse_values: "" => "false"
|
||||
skip_crds: "" => "false"
|
||||
status: "" => "deployed"
|
||||
timeout: "" => "300"
|
||||
verify: "" => "false"
|
||||
version: "" => "0.1.0"
|
||||
wait: "" => "true"
|
||||
|
||||
Error: Error applying plan:
|
||||
|
||||
1 error occurred:
|
||||
* helm_release.local: 1 error occurred:
|
||||
* helm_release.local: cannot re-use a name that is still in use
|
||||
|
||||
Terraform does not automatically rollback in the face of errors.
|
||||
Instead, your Terraform state file has been partially updated with
|
||||
any resources that successfully completed. Please address the error
|
||||
above and apply again to incrementally change your infrastructure.
|
||||
```
|
||||
|
||||
This creates a reuse issue due to commenting out and bringing back a resource. To fix this, do a state import, which allows you to take something that is already out in the environment and let Terraform start to track it again.
|
||||
|
||||
For this, you need the namespace and chart name you want to import along with the module name you are importing. The module in this case is `helm.local`, and it is generated from your resource code in the resource that begins with `"helm_release" "local"`.
|
||||
|
||||
For the reimport, you will need the namespace where the resource is currently deployed, so the import will look like `default/buildachart`. This format is required for anything involving a namespace:
|
||||
|
||||
|
||||
```
|
||||
jess@Athena:~/terraform_doc$ terraform import helm_release.local default/buildachart
|
||||
helm_release.local: Importing from ID "default/buildachart"...
|
||||
helm_release.local: Import complete!
|
||||
Imported helm_release (ID: buildachart)
|
||||
helm_release.local: Refreshing state... (ID: buildachart)
|
||||
|
||||
Import successful!
|
||||
|
||||
The resources that were imported are shown above. These resources are now in
|
||||
your Terraform state and will henceforth be managed by Terraform.
|
||||
```
|
||||
|
||||
This process of reimporting can be tricky, but it's important for state management.
|
||||
|
||||
### Clean up
|
||||
|
||||
What's so nice about Terraform is that you can quickly clean up after yourself when you're testing. The `follow` command is another great way to ruin your day if you aren't careful about where you run it:
|
||||
|
||||
|
||||
```
|
||||
jess@Athena:~/terraform_doc$ terraform destroy
|
||||
helm_release.local: Refreshing state... (ID: buildachart)
|
||||
kubernetes_namespace.1-minikube-namespace: Refreshing state... (ID: my-first-terraform-namespace)
|
||||
|
||||
An execution plan has been generated and is shown below.
|
||||
Resource actions are indicated with the following symbols:
|
||||
- destroy
|
||||
|
||||
Terraform will perform the following actions:
|
||||
|
||||
- helm_release.local
|
||||
- kubernetes_namespace.1-minikube-namespace
|
||||
|
||||
Plan: 0 to add, 0 to change, 2 to destroy.
|
||||
|
||||
Do you really want to destroy all resources?
|
||||
Terraform will destroy all your managed infrastructure, as shown above.
|
||||
There is no undo. Only 'yes' will be accepted to confirm.
|
||||
|
||||
Enter a value: yes
|
||||
|
||||
helm_release.local: Destroying... (ID: buildachart)
|
||||
kubernetes_namespace.1-minikube-namespace: Destroying... (ID: my-first-terraform-namespace)
|
||||
helm_release.local: Destruction complete after 1s
|
||||
kubernetes_namespace.1-minikube-namespace: Destruction complete after 7s
|
||||
|
||||
Destroy complete! Resources: 2 destroyed.
|
||||
```
|
||||
|
||||
One run of `terraform destroy` removed your pods and namespace, but your cluster remains. You are back to square one:
|
||||
|
||||
|
||||
```
|
||||
jess@Athena:~/terraform_doc$ kubectl get pods
|
||||
No resources found in default namespace.
|
||||
|
||||
jess@Athena:~/terraform_doc$ kubectl get ns
|
||||
NAME STATUS AGE
|
||||
default Active 28d
|
||||
kube-node-lease Active 28d
|
||||
kube-public Active 28d
|
||||
kube-system Active 28d
|
||||
|
||||
jess@Athena:~/terraform_doc$ minikube status
|
||||
m01
|
||||
host: Running
|
||||
kubelet: Running
|
||||
apiserver: Running
|
||||
kubeconfig: Configured
|
||||
```
|
||||
|
||||
### Final notes
|
||||
|
||||
To say you can make anything with Terraform is an understatement. It's a tool that can manage every aspect of environment creation and destruction. It has a powerful and simple concept of state management that can allow teams to stay in sync with the organization's intended infrastructure.
|
||||
|
||||
However, if you are not careful, this tool can be rather unforgiving. If you are moving state files and not paying attention, you can cause a bit of an issue with what Terraform believes it needs to manage. When you are using this tool, be careful not to overextend yourself or write too much at once, as you can code yourself into a corner if you aren't paying attention.
|
||||
|
||||
Terraform is best when it's used for infrastructure provisioning. It minimizes what problems happen when managing state, and allows tools designed for configuration and deployment to complement its features.
|
||||
|
||||
What have you done with Terraform and Kubernetes? Share your experience in the comments below.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/7/terraform-kubernetes
|
||||
|
||||
作者：[Jessica Cherry][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/cherrybomb
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/computer_keyboard_laptop_development_code_woman.png?itok=vbYz6jjb (A person programming)
|
||||
[2]: https://opensource.com/article/19/7/infrastructure-code
|
||||
[3]: https://thenewstack.io/what-is-gitops-and-why-it-might-be-the-next-big-thing-for-devops/
|
||||
[4]: https://www.terraform.io/
|
||||
[5]: https://github.com/hashicorp/terraform
|
||||
[6]: https://www.terraform.io/docs/providers/index.html
|
||||
[7]: https://releases.hashicorp.com/terraform/0.11.14/
|
||||
[8]: https://github.com/helm/helm/releases/tag/v2.16.7
|
||||
[9]: https://opensource.com/article/18/10/getting-started-minikube
|
||||
[10]: https://kubernetes.io/docs/tasks/tools/install-kubectl/
|
||||
[11]: https://kubernetes.io/docs/tasks/tools/install-minikube/
|
||||
[12]: https://github.com/helm/helm#install
|
||||
[13]: https://github.com/helm/helm/releases
|
||||
[14]: https://releases.hashicorp.com/terraform/
|
||||
[15]: https://www.terraform.io/docs/configuration/modules.html
|
||||
[16]: https://www.terraform.io/docs/state/index.html
|
||||
[17]: https://registry.terraform.io/providers/hashicorp/kubernetes
|
||||
217
sources/tech/20200706 Set up Vim as your Rust IDE.md
Normal file
217
sources/tech/20200706 Set up Vim as your Rust IDE.md
Normal file
@ -0,0 +1,217 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Set up Vim as your Rust IDE)
|
||||
[#]: via: (https://opensource.com/article/20/7/vim-rust-ide)
|
||||
[#]: author: (Daniel Oh https://opensource.com/users/daniel-oh)
|
||||
|
||||
Set up Vim as your Rust IDE
|
||||
======
|
||||
The Vim text editor is a great development environment for programming
|
||||
Rust applications.
|
||||
![Ferris the crab under the sea, unofficial logo for Rust programming language][1]
|
||||
|
||||
The [Rust][2] programming language is designed to implement systems programming with safe concurrency and high memory performance in a way that feels familiar to C++ developers. It's also one of the most loved programming languages in [Stack Overflow's 2019 Developer Survey][3].
|
||||
|
||||
Text editors and [integrated development environment (IDE) tools][4] make writing Rust code easier and quicker. There are many editors to choose from, but I believe the [Vim editor][5] is a great fit for a Rust IDE. In this article, I'll explain how to set up Vim for Rust application development.
|
||||
|
||||
### Install Vim
|
||||
|
||||
Vim is one of the most commonly used command-line text editors in Linux and Unix. The latest version (as of this writing) is [8.2][6], and it offers more flexibility than ever in how you can use it.
|
||||
|
||||
[Vim's download page][7] provides multiple options to install it with binary or packages. For example, if you use macOS, you can install the [MacVim][8] project, then expand Vim's capabilities by [installing Vim plugins][9].
|
||||
|
||||
To set up Rust for development, download [Rustup][10], a handy Rust installer utility, and run the following in your terminal (if you use macOS, Linux, or any other Unix-like operating system):
|
||||
|
||||
|
||||
```
|
||||
`$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh`
|
||||
```
|
||||
|
||||
Choose an installation option from the interactive prompt. Then you will see output like:
|
||||
|
||||
|
||||
```
|
||||
stable installed - rustc 1.43.1 (8d69840ab 2020-05-04)
|
||||
|
||||
Rust is installed now. Great!
|
||||
|
||||
To get started you need Cargo's bin directory ($HOME/.cargo/bin) in your PATH
|
||||
environment variable. Next time you log in this will be done
|
||||
automatically.
|
||||
|
||||
To configure your current shell run source $HOME/.cargo/env
|
||||
```
|
||||
|
||||
### Syntax highlighting
|
||||
|
||||
Vim allows you to configure your runtime by defining it in the `.vimrc` file. To enable syntax highlighting, open your `.vimrc` file (or create one if it doesn't exist):
|
||||
|
||||
|
||||
```
|
||||
`$ vim ~/.vimrc`
|
||||
```
|
||||
|
||||
Add the following in the `.vimrc` file and save it:
|
||||
|
||||
|
||||
```
|
||||
filetype plugin indent on
|
||||
syntax on
|
||||
```
|
||||
|
||||
The first line turns on the detection, plugin, and indent configurations all at once. The second line enables syntax highlighting. These features will help you manage your developer workflow in Rust. Learn more in Vim's [help file][11].
|
||||
|
||||
### Create a Rust application in Vim
|
||||
|
||||
To create a new Rust HelloWorld application (`hello.rs`) using Vim, enter:
|
||||
|
||||
|
||||
```
|
||||
`$ vim hello.rs`
|
||||
```
|
||||
|
||||
Enter the following Rust code to print **Hello World!** in the console:
|
||||
|
||||
|
||||
```
|
||||
fn main() {
|
||||
println!("Hello World");
|
||||
}
|
||||
```
|
||||
|
||||
It should look something like this:
|
||||
|
||||
![Rust code with syntax highlighting][12]
|
||||
|
||||
(Daniel Oh, [CC BY-SA 4.0][13])
|
||||
|
||||
Here's what it would look like without syntax highlighting:
|
||||
|
||||
![Rust code without syntax highlighting][14]
|
||||
|
||||
(Daniel Oh, [CC BY-SA 4.0][13])
|
||||
|
||||
Did you notice how Vim automatically indented and organized the code? That is because of the first line you entered in the `.vimrc` file.
|
||||
|
||||
Great job! Next, you will build this application using Rust's package manager, [Cargo][15].
|
||||
|
||||
### Cargo integrations
|
||||
|
||||
Cargo makes creating applications easier. To see how, create a Cargo-based HelloWorld application. If you don't already have Cargo installed on your Linux or macOS system, enter:
|
||||
|
||||
|
||||
```
|
||||
`$ curl https://sh.rustup.rs -sSf | sh`
|
||||
```
|
||||
|
||||
Then create a package with Cargo:
|
||||
|
||||
|
||||
```
|
||||
`$ cargo new my_hello_world`
|
||||
```
|
||||
|
||||
If you look at the directory structure, you'll see Cargo automatically generated some source code and directories. If you have `tree` installed, run it to see the directory structure:
|
||||
|
||||
|
||||
```
|
||||
$ tree my_hello_world
|
||||
my_hello_world
|
||||
├── Cargo.toml
|
||||
└── src
|
||||
└── main.rs
|
||||
|
||||
1 directory, 2 files
|
||||
```
|
||||
|
||||
Open the `main.rs` source code file in Vim:
|
||||
|
||||
|
||||
```
|
||||
`$ vim my_hello_world/src/main.rs`
|
||||
```
|
||||
|
||||
The code is the same as in the HelloWorld example you created manually above. Replace `World` with `Rust with Vim`:
|
||||
|
||||
|
||||
```
|
||||
fn main() {
|
||||
println!("Hello, Rust with Vim");
|
||||
}
|
||||
```
|
||||
|
||||
Use `:wq` to save your changes and quit Vim.
|
||||
|
||||
### Compile your application
|
||||
|
||||
Now you can compile your first Rust application using `cargo build`:
|
||||
|
||||
|
||||
```
|
||||
$ cd my_hello_world
|
||||
$ cargo build
|
||||
```
|
||||
|
||||
Your terminal output will look similar to this:
|
||||
|
||||
|
||||
```
|
||||
Compiling my_hello_world v0.1.0 (/Users/danieloh/cloud-native-app-dev/rust/my_hello_world)
|
||||
|
||||
Finished dev [unoptimized + debuginfo] target(s) in 0.60s
|
||||
```
|
||||
|
||||
You may see a warning message because you reused the sample package name, `my_hello_world`, but you can ignore it for now.
|
||||
|
||||
Run the application:
|
||||
|
||||
|
||||
```
|
||||
$ target/debug/my_hello_world
|
||||
Hello, Rust with Vim!
|
||||
```
|
||||
|
||||
You can also use `cargo run` to build and run the application all at once:
|
||||
|
||||
|
||||
```
|
||||
$ cargo run
|
||||
|
||||
Finished dev [unoptimized + debuginfo] target(s) in 0.00s
|
||||
Running `target/debug/my_hello_world`
|
||||
Hello, Rust with Vim!!
|
||||
```
|
||||
|
||||
Congratulations! You set up Vim editor for Rust IDE on your local machine, developed your first Rust application, and built, tested, and ran it using the Cargo package manager tool. Run `cargo help` If you want to learn other Cargo commands.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/7/vim-rust-ide
|
||||
|
||||
作者：[Daniel Oh][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/daniel-oh
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/rust_programming_crab_sea.png?itok=2eWLz8A5 (Ferris the crab under the sea, unofficial logo for Rust programming language)
|
||||
[2]: https://www.rust-lang.org/
|
||||
[3]: https://insights.stackoverflow.com/survey/2019#technology-_-most-loved-dreaded-and-wanted-languages
|
||||
[4]: https://en.wikipedia.org/wiki/Integrated_development_environment
|
||||
[5]: https://opensource.com/resources/what-vim
|
||||
[6]: https://github.com/vim/vim
|
||||
[7]: https://www.vim.org/download.php
|
||||
[8]: https://github.com/macvim-dev/macvim
|
||||
[9]: https://opensource.com/article/20/2/how-install-vim-plugins
|
||||
[10]: https://rustup.rs/
|
||||
[11]: http://vimdoc.sourceforge.net/htmldoc/filetype.html#:filetype-overview
|
||||
[12]: https://opensource.com/sites/default/files/uploads/rust_helloworld.png (Rust code with syntax highlighting)
|
||||
[13]: https://creativecommons.org/licenses/by-sa/4.0/
|
||||
[14]: https://opensource.com/sites/default/files/uploads/rust_helloworld_no-syntax.png (Rust code without syntax highlighting)
|
||||
[15]: https://opensource.com/article/20/3/rust-cargo
|
||||
Loading…
Reference in New Issue
Block a user